Sporadic crash while invoking ClipAngel in Visual Studio
Clipboard history capture and paste tool
Brought to you by:
tormozit
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.
Attaching the associated crash file from the Event Viewer, if it helps.
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:
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.
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?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?
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
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
The option "Fast window open" was already Off on my PC and my laptop...
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?
Good research. I will try to find such code and possibly make test build.
The №1 suspect is GetProcessMainModuleFullName(). Try to null it
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
I forgot that there is "Read window titles" setting which disables GetWindowTitle().
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.
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
Did uchecked "Read window titles" setting help?
Yes, I've unchecked that, thanks! Let me wait for results, since the crash may take several days to appear.
Any news?
No crashes so far.
Try check this setting back in this test build https://sourceforge.net/projects/clip-angel/files/ClipAngel%202.04%20test.zip/download
Try check this setting back in this test build https://sourceforge.net/projects/clip-angel/files/ClipAngel%202.04%20test.zip/download
Did new version pass test?
So far so good.
fix commit
https://github.com/tormozit/ClipAngel/commit/5cbdac3b8f3ce95238b39feaf80ef45743e2fe75#diff-8bed8c2318d615e4fc8ba5b31743510f2ec246c511b9b69be5e12d166b8d47f5
fixed in 2.04