On Windows 10 and using Visual Studio 2015, I'm trying to debug a WPF C# application that incorporates C++ PInvokes. After the app starts, a particular execution path causes the app to crash, which then shows this message:
vshost32.exe has stopped working
A problem caused the program to stop working correctly. Windows will close the program and notify you if the solution is available.
I take the "Debug" option provided on that dialogue, and then it says:
A debugger is attached to MyWpfApp.exe but not configured to debug this unhandled exception. To debug this exception, detach the current debugger.
This is frustrating. When the crash occurs, it is being debugged by Visual Studio 2015. Why is it "not configured to debug" this problem? Can the configuration be modified to catch this?
At this point I'm stuck. I tried issuing a "detach all" command to VS 2015, so that the OS can start a new debugger, but VS 2015 refuses to detach. If I instead simply stop VS2015, then the OS says that the crash can no longer be debugged, because the process was terminated.
In short, I can't debug the problem - even though I have best-in-the-industry tools pointed directly at it.
Any suggestions of how to debug this mysterious crash?
I do have additional information about this problem, because I also tried to debug it on a Windows 7 machine within Visual Studio 2013. It has the same crash. In this case, the crash simply causes the debug session in VS 2013 to suddenly end without warning - as if the program had terminated gracefully. In an effort to capture the crash, I activated crash dump capture via Windows Error Reporting (WER).
It worked! First, I got this info:
Unhandled exception at 0x77BC46A9 (msvcr120.dll) in MyWpfApp.exe: An invalid parameter was passed to a function that considers invalid parameters fatal.
The stack trace then showed me the exact line of managed code that transitions into unmanaged, and eventually reaches msvcr120 which crashes.
Unfortunately, after this initial success, my debugging success ended here because suddenly the WER configuration on the Windows 7 development machine simply stopped capturing any further crashes. I thought it was code changes I had made which jinxed WER, but when I reverted my changes WER continued to be unaware that the application was crashing.
So in the end, this crash is doing its best to be untrappable - preventing me from capturing a crash dump. I also tried running the app from the command prompt, and attaching sysinternals procdump to it:
c:\>procdump -ma -e -accepteula -x . MyWpfApp.exe
Surprisingly, this also didn't work. The OS caught the crash and reported it, while procdump was entirely unaware the crash had occurred.
Is there a "bigger hammer" I can use that will ensure I can capture crash dumps?
Related
I have written a Windows 10 IoT (UWP) application running on a Raspberry PI 3. The application is a client to Azure IoT Hub and is also using interfaces to Azure Event Hub and Azure Table Storage.
Once now and then I get the following exception logged to the Output window in VS 2017:
An unhandled exception of type
'System.Runtime.InteropServices.SEHException' occurred in
System.Private.CoreLib.ni.dll External component has thrown an
exception.
I’m running the app in VS 2017 to try to figure out why the application crashes. It typically runs fine for several days until it crashes with this error.
It doesn’t seem like the crash is caused by my own code. None of my own exception handlers are invoked and I don’t see any relevant call stack info.
Does anyone know how to nail down a crash like this?
Make sure that "Break When Thrown" is enabled for the exception type (settings are in Debug -> Windows -> Exceptions). This will cause the debugger to stop where the problem occurs and makes it easier to figure out where the problem is.
I have created a service using C# with Visual Studio 2010. Using .NET Framework v4.0. Running on Windows 7, 32 bit machine. The service calls into a native DLL I created. This DLL is throwing an access violation.
I can't debug it and need help.
I start the service and run my IDE as Administrator. The service is running under the same user account as I am logged into the machine as. I attach to the service using Managed v4.0 and Native attach code types. But when it crashes, a dialog pops up that says "An unhandled Microsoft .NET framework exception occurred" in my app. "The Just-In-Time debugger was launched without necessary security permissions. To debug this process, the Just-In-Time debugger must be run as an Administrator. Would you like to debug this process?". Even though I launched Visual Studio with "Run As Administrator".
When I click "Yes" I get another warning "The current debugger is configured to debug code that uses Microsoft .NET Framework v1.0, 1.1, or 2.0. An unhandled exception is being thrown from .NET Framework v4.0 code". Even though I attach to the process using Managed v4.0 and Native. (I've tried just with Managed v4.0 and get same results).
I click okay, and launch a new instance of the IDE. The IDE then displays a warning that says it is "Unable to attach to the crashing process. A debugger is already attached."
So I try again, this time without attaching debugger hoping to get the same JIT pop-up so I can then attach after the crash, but I don't. The process just goes away or I get the usual dialog about creating a mini dump and sending it to Microsoft.
So I tried settling for full crash dump.
I followed the instructions at Collecting User-Mode Dumps to create full dumps. I'll watch as WerFault.exe starts in task manager and watch the file get created and when WerFault it's done, either the crash dump disappears or stack trace is missing native code.
I seem to have similar problems debugging .NET processes from time to time. How can I reliably configure my computer so I can get JIT debugging?
I am developing an app to install & run as a Windows service. It's still buggy and stopped unexpectedly (leaving nothing in the Windows Event log either) and when I tried to start it up again I got the error
Windows could not start the {name of service} service on Local Computer.
Error 1067: The process terminated unexpectedly.
I restarted the computer (Server 2008 R2; a virtual machine, in case that makes a difference), no help. Uninstalled and reinstalled my service, and still get that error!
Something on the machine needs cleared out / refreshed so that it will attempt to start the service again. I don't want to rebuild the whole virtual machine but I'm out of ideas.
UPDATE
I forgot to mention that this Windows service -- exact same code & install -- is running on 3 other machines without the above error. Putting in that debugger in OnStart() still sounds like the way to go though.
If you have access to the code, you can add a method Debugger.Break at the first line of the OnStart method.
Once you "break" into the application investigate where the exception is thrown.
You can attach the debugger to a running service. Details at Debug Windows Service Applications.
It's fortunate that you can replicate the problem easily. You can install the .NET Studio with code to debug your problem.
Another technique is to make the Service into a regular app. You know that the suspect code is during Startup. So simply create the app with code in the Startup function, and start debugging from there.
Good luck,
Tommy Kwee
I have a command line Mono application running on the Mac (OSX Lion) and it dies misteriously with the following message:
[1] 53342 trace trap "/Library/Frameworks/Mono.framework/Versions/2.10.9/bin/mono" --debug
read: -p: no coprocess
This is running the app from MonoDevelop.
Anyone has any idea what is happening and how I can fix this? (or how I can try to figure out what it is)
Neither how to fix it, nor how to figure out what it is, but to isolate the problem:
Run it outside MonoDevelop. If it works, report a bug to MonoDevelop.
Run it outside MonoDevelop with the latest version of Mono (2.11.3). If it still fails, file a bug to Mono.
(If you have access to a Linux box, try there too because it may be a bug in Mono that only affects Mac platform.)
Bugs are filed in http://bugzilla.xamarin.com/
In the end the issue was that there was code like this in the app:
#if DEBUG
Debugger.Break();
#endif
The application was being compiled in Debug and I was running the app like this:
mono Cli.exe
And when the interpreter found this piece of code, there was no debugger available when the trap signal was sent. While on Windows a dialog is opened asking you if you want to debug the app, on MacOS the application just commits suicide. The fix was to not execute this code if running on a Mac (or running the app inside of GDB).
My application crashes after some time but I can't find any pattern. I was able to get my hands on crash dump. Application runs on Windows Mobile 6.5. It is written in C#. It uses Imaging API, PInvoks and lots of threads.
When I debugged that dump with Visual Studio 2008, in output it displayed "First-chance exception at 0x782260ec in xxx.exe: 0xC0000005: Access violation"
Call Stack shows 2 entries. But I can't match any of them to call from my code.
windbg.exe indicates that this error occurs in "netcfagl3_5.dll"
Are there some special techniques to analyze dump files from Windows Mobile??
0xC0000005: Access violation means that one of your p/invokes are incorrect. The call tried to write to a memory area which it doesn't have access to (which is typical if the definition is incorrect).
Your dump should contain a stack trace too?
'First-chance exception' usually means an exception that has been handled by user code. If you're using the Vosual Studio & the Windows Mobile emulator for debug then you can turn off exception handling. Go to Debug > Exceptions and check the 'Thrown' column for Win32 Exceptions. Then run the program and try and get it to fall over again.
When the debug runs it will halt execution and break to the debugger when it hits that 'first-chance exception' allowing you to see what is causing that, and see if it's in any way related.
The 'netcfagl3_5.dll' library is part of .NET CF, not your code, which is why you can't match up the debug symbols.
You will need to download windbg, Visual Studio 2008 won't do Post Mortem .NET debugging.
If your development machine is 64-bit, see "How to use Windbg to debug a dump of a 32bit .NET app running on a x64 machine"
Otherwise, see Post Mortem Debug under Windows Mobile with WinDbg. also do some searching on "Windows Mobile Post Mortem Debug".
The best (by far) and easiest way, though is to reproduce this issue while running on the debugger. Post mortem .net debugging is NOT easy.
-PaulH