Menu

#135 Sporadic crash while invoking ClipAngel in Visual Studio

1.0
accepted
nobody
None
2022-11-14
2022-05-12
DV
No

I deal with Visual Studio 2017 to develop C++ projects. I use it under Windows 10 Pro 64-bit and under Windows 8.1 Single Language 64-bit.
I've assigned Ctrl+Alt+V to invoke ClipAngel.
When I press Ctrl+Alt+V in Visual Studio while working with C++ source code, rarely ClipAngel seems to crash right after Ctrl+Alt+V has been pressed. This happens under the mentioned Windows 10 64-bit and Windows 8.1 64-bit. What is interesting, ClipAngel keeps most of the clipboard history after it is restarted, it loses just a few last items.
Originally I had an impression that this crash was introduced in ClipAngel 2.03, but recently I had the same crash with 2.01.

Discussion

1 2 > >> (Page 1 of 2)
  • DV

    DV - 2022-05-12

    Attaching the associated crash file from the Event Viewer, if it helps.

     
  • DV

    DV - 2022-05-12

    Here is another extract from Event Viewer:

    Faulting application name: ClipAngel.exe, version: 1.0.0.0, time stamp: 0x6155e8f3
    Faulting module name: ntdll.dll, version: 6.3.9600.20144, time stamp: 0x615be385
    Exception code: 0xc0000374
    Fault offset: 0x000e5f44
    Faulting process id: 0x15f0
    Faulting application start time: 0x01d7d7b8877adc6c
    Faulting application path: C:\Progs\Progs\ClipAngel\ClipAngel.exe
    Faulting module path: C:\windows\SYSTEM32\ntdll.dll
    Report Id: ca6cfae2-43b2-11ec-854d-742b627a8148
    Faulting package full name:
    Faulting package-relative application ID:

     
  • tormozit

    tormozit - 2022-05-12

    We need to find conditions for crash reproduction. Make ClipAngel window always on top. You can also make it very small size. Next time when ClipAngel window disappear (crash), examine data in clipboard and try to reproduce crash.

     
  • DV

    DV - 2022-05-26

    The issue seems to be really rare and sporadic. I can't reproduce it when I try intentionally.
    However, I had several crashes during this week. All of them happened at the moment of Ctrl+Alt+V (when ClipAngel was expected to be shown, but it was not because it crashed). It happened a few times when I was about to paste into Visual Studio and a few times when I was about to paste into a web browser. And, as far as I noticed, the very same text can be successfully pasted at different moments of time. So I just don't understand why these rare crashes occur.
    Can it be investigated more by using some version with additional logging? Or maybe I should always start ClipAngel by means of procdump -t and share the dump file if it will be produced?

     
  • DV

    DV - 2022-07-13

    While running ClipAngel by means of procdump, I was able to collect two crash dumps. The dump analysis, however, does not seem to be verbose for .NET as the analysis deals with unmanaged code - or maybe it is just me who does not know how to collect and analyse crash dumps for .NET application properly.
    Anyway, here is what I could collect from the dump analysis:

    PROCESS_NAME: ClipAngel.exe
    ERROR_CODE: (NTSTATUS) 0xc0000374 - A heap has been corrupted.
    EXCEPTION_CODE_STR: c0000374
    EXCEPTION_PARAMETER1: 00000000770f3960
    FAULTING_THREAD: ffffffff

    Even this brief information seems to highlight the following things:
    1) It looks like ClipAngel has some code that calls native (unmanaged) functions directly (otherwise I don't understand how a heap corruption may occur)
    2) It looks like some of these unmanaged calls are related to reading information from the clipboard, and probably the heap corruption happens in one of these methods (this assumption is based on the fact that the crash happens when I press Ctrl+Alt+V to invoke ClipAngel's window. Another possibility is that ClipAngel may use native functions to show its main window and the stack corruption happens in one of those functions).

    Do you know a proper way to create a .NET crash dump for the further .NET crash dump analysis?

     
  • DV

    DV - 2022-07-13

    By the way, from my C++ experience, a heap corruption may be a consequence of incorrect calling convention - e.g. when __stdcall is not directly specified for WIN API functions and thus __cdecl is used instead, causing incorrect handling of the stack.

     

    Last edit: DV 2022-07-13
  • tormozit

    tormozit - 2022-07-13

    ClipAngel may use native functions to show its main window

    Yes. Due to NET slow window opening I made tricky ClipAngel window close/open mode using WinAPI. By default this "Fast window open" setting is ON. Try set it OFF.

     

    Last edit: tormozit 2022-07-13
  • DV

    DV - 2022-07-14

    The option "Fast window open" was already Off on my PC and my laptop...

     
  • DV

    DV - 2022-08-08

    I had downloaded the latest sources from GitHub and built them. Then I followed this instruction to have a .dmp file created automatically on crash:
    https://keithbabinec.com/2018/06/12/how-to-capture-and-debug-net-application-crash-dumps-in-windows/
    Today this version has crashed. I've followed the same instruction to analyze the crash dump. Unfortunately, I was not able to get into the .NET call stack (as in the example), however I've noticed a few important things:
    1) Looking into the time of the .dmp, the crash itself seemed to happen before I pressed Ctrl+Alt+V. (The .dmp file had been created at 5:04 PM whereas the Ctrl+Alt+V that did not show ClipAngel's window has been pressed at 5:07 PM). At that time (around 5:04 PM) I was actively copying, cutting and pasting in Visual Studio 2019. At some moment I noticed that an empty string has been pasted instead of a non-empty string - it either may be related to the ClipAngel's crash or it may be a mistaken cutting of an empty string.
    2) The analysis of the .dmp file has reported the following things:

    PROCESS_NAME: ClipAngel.exe
    ERROR_CODE: (NTSTATUS) 0xc0000374 - A heap has been corrupted.
    EXCEPTION_CODE_STR: c0000374

    FAILURE_BUCKET_ID: HEAP_CORRUPTION_ACTIONABLE_BlockNotBusy_DOUBLE_FREE_c0000374_ntdll.dll!RtlpFreeHeapInternal

    The last thing seems to be more interesting than the others. I mean, it assumes that some already released memory is attempted to be freed again.
    If we combine it with the observation #1 (that the crash seemed to happen during intensive Ctrl+X/Ctrl+V combinations), could it be that ClipAngel constantly allocates and deallocates memory while "watching" the clipboard activity, and some deallocations may try to free an empty or invalid block of memory?

     
  • tormozit

    tormozit - 2022-08-08

    Good research. I will try to find such code and possibly make test build.

     
  • tormozit

    tormozit - 2022-08-08

    The №1 suspect is GetProcessMainModuleFullName(). Try to null it

     
  • tormozit

    tormozit - 2022-08-08

    The №2 suspect is GetWindowTitle(). Try to null it. There already was heap corruption bug
    https://sourceforge.net/p/clip-angel/tickets/20/

     

    Last edit: tormozit 2022-08-08
  • tormozit

    tormozit - 2022-08-08

    I forgot that there is "Read window titles" setting which disables GetWindowTitle().

     
  • DV

    DV - 2022-08-09

    Sorry, what do you mean by "Try to null it"? Should I disable (comment out) the corresponding code? Or should I force the corresponding code to return null?

    As a non-related question (but related to ClipAngel), I noticed a strange behavior with regards to Ctrl+Shift+V (paste as plain text). You see, I have Ctrl+Shift assigned to change input language in Windows, and each time I press Ctrl+Shift+V, it pastes a plain text plus it changes the input language. I'd expect ClipAngel to remove the Ctrl+Shift keyboard event from the queue when it processes Ctrl+Shift+V, but apparently it does not happen.

     
    • tormozit

      tormozit - 2022-08-09

      Or should I force the corresponding code to return null?

      Yes. 99% chance that it will solve problem. But best result will be - find solution without loss of feature.

      For non-related question you should create new ticket.

       

      Last edit: tormozit 2022-08-09
  • tormozit

    tormozit - 2022-08-10

    Did uchecked "Read window titles" setting help?

     
  • DV

    DV - 2022-08-10

    Yes, I've unchecked that, thanks! Let me wait for results, since the crash may take several days to appear.

     
  • tormozit

    tormozit - 2022-08-15

    Any news?

     
  • DV

    DV - 2022-08-15

    No crashes so far.

     
  • tormozit

    tormozit - 2022-08-20

    Did new version pass test?

     
  • DV

    DV - 2022-08-20

    So far so good.

     
  • tormozit

    tormozit - 2022-08-20

    fixed in 2.04

     
1 2 > >> (Page 1 of 2)

Log in to post a comment.