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
Related
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?
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?
I developed a small app used to synch data between a local computer and an online web service.
In the testing environment, using visual studios 2012 express debug mode, I'm not able to reproduce a bug that is causing the application to crash.
I've tried logging activity manually by writing data to .txt file to give me a frame of reference, but I still can not determine where this bug is occurring.
Are there any tools available for debugging this app while in production mode?
If you can start a process on the remote production machine, the simplest thing to do in this kind of scenario is using the VS remote debugger.
This way you'll have a full debugging context with much more information than with simple logging; the debugging experience is (almost) the same as with local debugging.
It's a shame this tool is not widely known because it can literally save you hours or even days for tricky bugs.
Try logging stacktrace a.s.o. in AppDomain.UnhandledException event handler.
Furthermore it's possible to trace all function calls utilizing aspect oriented programming with PostSharp. There are examples on the PostSharp webpage.
We use Microsoft Enterprise Library to log and email the stacktrace to us any time an unhandled exception occurs.
Simply use NBug library which can catch unhandled applications and send a bug report to an e-mail address that you specify.
Yeah, the problem could be related to environment or the version of the software your debugging is not the same as production. So what you ideally want is to debug the live version against the same source code version and debug symbol files.
There are numerous articles on the net regarding how to do this like this one and this one. I read one once that showed you how to not only setup a symbol server correctly with TFS but on how to debug an production exe and VS would load the correct symbols for that version from the symbol server and the source code version from TFS... but alas i cannot find it.
The remote debugging an logging is all great essential tools but when you're at the place you're at now - the right version of debug symbols and source code would probably help you more.
I have just started working on a Windows Store App written in C#, it has not yet been published to the Windows Store. When I give a debug build of the app being developed to my testing team and it crashes where can they find the crash log and stack trace? Do I need to do anything when building my application? I'm looking for the standard solution, not a third party library or something that sends me reports from end-users. I'm coming from an Android world where the ADB logcat always contains the Java stack trace, I'm looking for the equivalent in C#/WinRt.
Crash dumps will contain the callstack and much more.
To collect crash dumps, first, execute the following regedit script:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps]
"DumpFolder"="C:\\Temp\\CrashDumps"
"DumpCount"=dword:00000002
"DumpType"=dword:00000002
Second, reproduce the crash.
Third, stop crash dump recollection by executing:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps]
"DumpFolder"=-
"DumpCount"=-
"DumpType"=-
Fourth, get the crash dump from C:\Temp\CrashDumps
More info at MSDN.
I've copied over the content of the Debug folder on a Windows 7 VM and a Windows Vista laptop. Both had Dot Net 4.5 installed. All assemblies are set to copy local and AFAIK I don't reference anything not in the application folder. When I run the app on the two different developer computers (one Win8, one Win7) it runs fine as it does when running it in Visual Studio (F5).
Not so on the deployment computers. The problem is that I get no error message. Absolutely nothing happens after I double click the executable on the non-development machines.
I tried starting it in WinDbg.exe and got this output: http://pastebin.com/43PbwyGx
So how to I go about debugging this to find out what's missing?
looking at your WindDbg dump you have an 2nd Chance Execption of CLR exception - code e0434352 (!!! second chance !!!).
I would look at this article by Igor Dvorkin, Why do I keep getting exception code e0434352.
Where he discusses it being a generic exception and how to fire up the cdb to find what the underlying exception was.
He also links to another of his blog posts, Finding CLR exceptions without visual studio where he describes using cdb.
Are the dev machines 64-bit but the other machines 32-bit? If this is the case and you're building as AnyCPU, then all your references also need to be AnyCPU (or match the platform your program is running under). If you build as x64, then I think all your references need to be x64 as well, and the same goes for x86.
Usually the exception you'll see in this case is a BadImageFormatException (it's also typically logged to the Windows Application Event Log with a source of Side By Side Configuration).
Also, just an FYI, sometimes you might be able to find the exception in the Windows Event Log. I think it's the Application Log, and I think the Source is usually .NET Runtime, or Application Error. The details may include both the actual exception as well as a stack trace.
I'm not sure what conditions need to be true for these errors to be logged, but it's something to consider.