Let's say I have a .NET application that crashes when I close it and I want to use DebugDiag to see what is going on. So we should create a dump file. My question is When do we create this dump file? Should I create it when I start the application? well if I do that it says a dump file has been created at this temp location...ok..then I continue working the application and make it to crash, but my confusion is that well it created the dump file very early, but crash happened at the end, so how even that dump file can be helpful? does it like get updated automatically once we are working with that application?
For a crash (which is usually an unhandled exception) you should create the dump file when the exception becomes a second chance exception. I am not very familiar with DebugDiag, but tools such as adplus (Debugging Tools for Windows) and ProcDump will both let you create dumps for this.
In some cases you may want to create dumps for first chance exceptions as well (i.e. before any code gets to handle the exception). E.g. if the exception which causes the crash wraps some other exception you may not have enough information at that point. In those cases creating dump files on first chance exceptions will give you detailed information on the state of the original exception.
You can configure windows to create dump files when the process crashes. This feature is not enabled by default: Collecting User-Mode Dumps. The process is different for Windows XP: Capturing Application Crash Dumps. Once you have the dump file you can open it and investigae with WinDbg. I highly recommend blog by Tess Fernandez and this book.
Related
I have console application which is executed in another app. The problem is that the second app cannot catch the exceptions that first one throws (run with Process). So I have to write some class that contains my return code and appropriate message.So that the app which runs my executable can use it and show error message depending on return code. But I don't know how this kind of thing should be done.
This is an old post i stumbled on but why not answer?
I think what you are looking for is the error stream. In windows and most other systems the OS references it as stderr. I'll post some links for reading, but in essence, separate execution environments or applications only return codes that tell the OS weather or not an application exited (finished) successfully (0) or encountered an error (-1). In windows there are two separate streams stdout which we write execution messages to, or stderr which we write errors too. Those steams can then be read by your other application. Look at these for more info:
How to capture a Processes STDOUT and STDERR line by line as they occur, during process operation. (C#)
https://msdn.microsoft.com/en-us/library/system.diagnostics.process.standarderror(v=vs.110).aspx
https://msdn.microsoft.com/en-us/library/system.diagnostics.process.standardoutput(v=vs.110).aspx
Depending on your needs there are some other more complex solutions such as the "Interoperability Library" or writing to file.
Interop info:
https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/interop/
By my application am creating a pdf file & sharing it via Share Charm. In most times i could successfully sharing the document to Sky Drive, Mail etc..
But at rarely when i sharing the same document am getting an error message like "Something went wrong Couldn't share Document with SkyDrive"
& after that i couldn't share that document. I want to know about at whatever conditions this error may occurs?
If its a generic message such as: Something went wrong with Share. Try again later - when you run the app from VS, then this might help (from here- images):
Open Task Manager, end the explorer.exe task (Details tab).
Select Run new task from File in Task Manager and type in explorer in the textbox and click OK.
If it is specific to Sky Drive then it is likely that it has something to do with the Sky Drive application and not your app. I'm unable to replicate the problem you are having.
I would try to isolate the error and see exactly what triggers the error.
Start with debugging the share charm, but keep in mind that if you end the debug session in the datarequest handler the charm might break and stop working, and you will need to apply the dirty fix I wrote above.
Output what happens to a file and run the share until you get the problem, and see if there is anything in the file that can help you figure out the problem.
Also, check the event log on you computer for a hint, I tend to use powershell for those things, open powershell in admin mode and run Get-EventLog Application -newest 10 | Format-List . Otherwise type Event Viewer while in the 'Metro' mode and look under Applications.
From MSDN- on common issues with the Share
Common issues
Unhandled exceptions in a target app cause it to immediately terminate and be replaced with an error message. The target app should gracefully handle any expected errors originating from the user, such as invalid input data, and report them to the user.
If a target app takes too long to respond to an activation event, the system assumes that the app is choosing not to respond and displays an error. Processing data should be moved out of the activation handler whenever possible, typically by storing a ShareOperation object and processing it asynchronously.
Calls to sharing the API can throw exceptions when called too many times or in the wrong order. When you implement a long-running share, be sure to call the share methods in the following order, without calling any single method twice in a row.
ReportStarted
ReportDataRetrieved
ReportSubmittedBackgroundTask
You can call ReportError or ReportCompleted at any time to complete the sharing operation.
To learn more about the share API, see Windows.ApplicationModel.DataTransfer.ShareTarget namespace.
Got a working solution to this problem
See this links
How to share a file that has been created on the fly
Share Contract Closes Immediately
I have the following strange behaviour in my Windows phone 8, C# App.
I am saving a Setting with:
private void SaveProperty<T>(T property, string propertyName)
{
if (IsolatedStorageSettings.ApplicationSettings.Contains(propertyName))
IsolatedStorageSettings.ApplicationSettings[propertyName] = property;
else
IsolatedStorageSettings.ApplicationSettings.Add(propertyName, property);
IsolatedStorageSettings.ApplicationSettings.Save();
}
When the app runs, I can read all settings I stored in IsolatedStorageSettings.ApplicationSettings.
But when I re-open my app (open it from the app list), the IsolatedStorageSettings.ApplicationSettings-Dictionary contains Zero (0) Keys and Values.
Am I missing something?
I used the ISETool.exe to take snapshots of the IsolatedStorage of my app (thanks to chepene).
I saw this behaviour: when I wrote the Settings (that means after the SaveProperty<T>() function finished), and the app is still running, I have the Settings saved in _ApplicationSettings. This agrees with my Observation that I can read from the IsolatedStorageSettings.ApplicationSettings when the app is running.
The _ApplicationSettings-file also exists when the is tombstoned or not running (when I can Access it by Holding the back-button of the phone and when the app is closed with the back-button).
But when the app is opened again (via the app list), the _ApplicationSettings-file is gone...
I also see that, when I'm writing a file into the IsolatedStorage with:
SharedStorageAccessManager.CopySharedFileAsync(
Windows.Storage.ApplicationData.Current.LocalFolder, fileName+"orig",
Windows.Storage.NameCollisionOption.ReplaceExisting, fileID);
and when I then don't read this file, it is gone when I open the app the next time.
By the way, to avoid confusion: I am not reinstalling the app each time I open it.
If you need more Information please ask.
Any help appreciated.
With AppSettings, I've seen something similar on WP7/7.5, but it happened only when my property-value's type was a class that was not known to the serializer.
Are you sure that there were no exceptions:
during Save
during App Exit (since the App may dump the settings at that point)
during the time that App loads the settings for the first time after launch?
Note that this doesn't necessarily must mean the app crashing. I mean, any exceptions, those internally silenced or user-handled too. Please check the VisualStudio's Output panel for "first chance exceptions" log. If any I/O or security or serialization exception shows up, then investigate there. If i remember well, there's even a whole set of isolated-storage exceptions that are easily interceptable from debug/exceptions menu.
However, the issues I had with unknown or nonserializable types does not explain at all why your extra non-appsettings files would evaporate.
Another thought: maybe some additional tool performs something like 'clean deploy' for you? I don't remember exactly, but I think that VisualStudio's deployment cycle was quite plain:
rebuild
remove/uninstall old app from device -- so probably purges isolatedstorage
install new app onto device
So, maybe that's the cause? Hm.. on afterthought and re-reading your question again, you've said about running the app from the applist, so that rather is not the case. Be sure to check firstchance exceptions then!
Thanks to quetzalcoatl I found the solution:
I am storing all my files in the root Folder of my app. At the start I am then reading all my files (via a DataContractSerializer) and casting it to my model. Since it happens sometimes that my files get corrupt, I delete every file which throws a SerialzationException. But as I read every file, and since _ApplicationSettings is not castable to my model, I am deleting _ApplicationSettings automatically.... So I learned that the ApplicationSettings are,just a file in the root folder, which I am allowed to read and delete. So the quintessence is to never write into the root Folder.
I've got an Umbraco site using a fair ammount of usercontrols in which, somewhere - somehow, a stackoverflow exception gets thrown every now and then.
Since the SOE doesn't occur when testing is has something to do with a user posting or getting some information (fair enough: something I've missed).
How can I trace back where my stackoverflow exception took place inside my code? Are there tools available to check my sources to see if I've missed some recursive method? Or how can I debug the running process?
I have found that debugging the application (sometimes having to attach VS to the correct w3wp.exe process) and setting VS to break on exception is the most helpful. You could still see the stack trace which is full of the same series of method calls.
If the application crashes, enable this registry setting to create a crashdump for all crashing apps:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps]
"DumpFolder"="C:\\TEMP"
"DumpCount"=dword:00000010
"DumpType"=dword:00000002
It will create a crash dump in your C:\Temp folder. Either open this dump file in a newer version of Visual Studio which will show you the exact code it crashed (just like if you where debugging and you got an unhandled exception).
Or an extremely useful MS tool for all your dump analysis needs: Debug Diagnostics Tools (https://www.microsoft.com/en-us/download/details.aspx?id=49924). Video walkthrough here: https://channel9.msdn.com/Shows/Defrag-Tools/Defrag-Tools-123-DebugDiag-Part-3
This will analyse your crashed application and show you all the threads and their managed and unmanaged stacktraces.
It will likely point out exactly the issue of your crash and where it occurred so you can check that stacktrace.
If however the program did not crash, you can open task manager and rightclick the process and create a dump file manually. Sending this dump file through Debug Diagnostics on a crash analysis it will show you the last X exceptions that did occur in your application with stacktraces. I use this method to find the actual error of user applications when the user gets a nice simplified error message. As an alternative to creating a dump from taskmanager you can also use procdump.exe or Debug Diagnostics itself to create rules on when to create dump files.
I really believe more people should be aware of how incredible easy a DUMP file together with Debug Diagnostics is to find any error that occurred in a production environment, where we don't have our handy development tools available.
I work on an open source product called EVEMon written in C# targeting the .NET 2.0 platform, I have one user who is suffering from a strange .NET crash that we have been unable to resolve.
Event Type: Error
Event Source: .NET Runtime 2.0 Error Reporting
Event Category: None
Event ID: 5000
Date: 4/29/2009
Time: 10:58:10 PM
User: N/A
Computer: removed this
Description:
EventType clr20r3, P1 evemon.exe, P2 1.2.7.1301, P3 49ea37c8, P4
system.windows.forms, P5 2.0.0.0, P6 4889dee7, P7 6cd3, P8 18, P9
system.argumentexception, P10 NIL.
Data:
//hex representation of the above Description
The application itself crashes with out displaying an error (despite having a error handling UI), the above messages was copied out of the Windows Event log. The end user has re-installed .NET and updated to the latest versions. The .PDB files are distributed with every release version of the program to aid in debugging and testing, the user with the problem in question has the full complement of PDB files for the correct version of EVEMon.
Is there a specific, tried and tested technique to analyse and diagnose this type of crash? and if so what tools and technologies are available to aid in debugging?
Special Thanks
I would like to give special thanks to Steffen Opel and highlight that his answer whilst not directly answering the question I was asking, addressed the bigger issue with my code base that the global error handling was missing an important component.
This is how I would tackle the problem for a end user with a crash.
Download and install Debugging Tools for Windows at http://www.microsoft.com/whdc/devtools/debugging/default.mspx
Once the tools are installed (they end up going to C:\Program Files\ by default) start a command line window.
Change to the directory which contains adplus (e.g "C:\Program Files\Debugging Tools for Windows (x86)").
Run the follwing command. This will start the application and attach adplus.
adplus -crash -o C:\debug\ -FullOnFirst -sc C:\path\to\your\app.exe
After the crash dump is created
Once the application crashes start WinDbg and load the .dmp file that is created in C:\debug. (File --> Open Crash Dump)
Execute these commands to see the stack trace and hopefully find the problem.
To load SOS for debugging
Pre .NET 4.0
.loadby sos mscorwks
.NET 4.0
.loadby sos clr
To see the stack trace
!clrstack
To see a more useful stack trace
!clrstack –p
To poke inside an object..perhaps see what caused the exception
!do <address>
e.g This is the result from a application that faulted randomly with an IO exception. WinDbg pointed out the path that was being referenced which was incorrect.
0:009> !do 017f2b7c
Name: System.String
MethodTable: 790fd8c4
EEClass: 790fd824
Size: 124(0x7c) bytes
(C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
String: \\server\path\not_here.txt
Fields:
MT Field Offset Type VT Attr Value Name
79102290 4000096 4 System.Int32 1 instance 54 m_arrayLength
79102290 4000097 8 System.Int32 1 instance 53 m_stringLength
790ff328 4000098 c System.Char 1 instance 5c m_firstChar
790fd8c4 4000099 10 System.String 0 shared static Empty
>> Domain:Value 00161df8:790d884c <<
7912dd40 400009a 14 System.Char[] 0 shared static WhitespaceChars
>> Domain:Value 00161df8:014113e8 <<
Peeking into your source code (trunk) indicates that your unhandled exception handling seems to be incomplete in regard to Windows Forms applications:
You need to handle both non-UI thread exceptions and UI thread exceptions:
For the former you need to implement a CLR unhandled exception handler via AppDomain.CurrentDomain.UnhandledException, which is in place already.
For the latter you need to implement a Windows Forms unhandled exception handler via Application.ThreadException, which seems to be missing; this could indeed yield exactly those problems you are witnessing. For an implementation example see MSDN documentation of Application.ThreadException Event.
Please note that right now you explicitly suppress catching unhandled Windows Forms exceptions via Application.SetUnhandledExceptionMode(UnhandledExceptionMode.ThrowException), you'll need to change this to UnhandledExceptionMode.CatchException to enable routing to your handler for Application.ThreadException, as correctly suggested by Jehof already.
What OS (Windows XP, Windows Vista, etc.) does the user use?
If Windows Vista try to disable "Problem Reports and Solutions feature" (Control Panel-->Problem Reports and Solutions-->Change Settings-->Advanced Settings-->Turn off for my programs, problem reporting)
Or try to set
Application.SetUnhandledExceptionMode( UnhandledExceptionMode.CatchException );
This will always route exceptions to the ThreadException handler.
In a nutshell: there is an unhandled exception in the application.
If you have access to the machine (through remote access, etc.), try installing Visual Studio Express and starting the application. You should see a dialog offering the chance to debug the application with a new instance of Visual Studio.
It may also be that there is something preventing Windows Forms from properly initializing. I've seen forum posts that suggest that font issues can cause this -- ensure that the users have the fonts installed that your application needs plus the usual defaults such as MS SansSerif, Arial, Tahoma, Times and suchlike.
And failing that... try sacrificing a chicken over the PC. Works a charm every time!
We've had issues with Exceptions in Thread-Code. If you spawn a new Thread and forget to handle an exception in the thread method, the application just "stops" - no error message, no nothing, but only an entry in the Event Log. Not even then UnhandledExceptionHandler is triggered.
Maybe something like this is the cause?
...if you are able to contact that suffering user, here is an
Idea: log pre-execution stages
Instead of making a shortcut to your program.exe, make a shortcut to program.bat, which will
echo "Pre-start" > stage.txt
start program.exe
The first line of Program.cs will therefore be
File.WriteAllLines("stage.txt", "Program execution started.");
In the handler of AppDomain.UnhandledException first line will be
File.WriteAllLines("stage.txt", "Unhandled exception has been caught.");
Also, make sure that the handler does not allocate memory or resources — pre-allocate them on programs start. Handler only trigger the writing to the log.
Comments
It is very likely that the stage.txt (sent by the user) will contain "Pre-start". This happens when an exception is thrown in 3rd party .dll — even before your program has started.
In that case you will need a simple checker program, which will not reference the assemblies that you program.exe does, but will Assembly.Load(...) them.
P.S.
stage.txt should be placed somewhere under %APPDATA%, not in Program Files.
I found an interesting case on Server 2003 and another nice discussion.
You should get a more detailed stack trace by sending the .pdb file for that particular release to the user (to be put next to the .exe) and having them reproduce the crash.
You should handle AppDomain.UnhandledException in code.
There was a similar question asked. See related ones too.