I have configured DebugDiag to monitor all app pools for crashes. One of our App pool stopped today but DD did not generate any dump files. Event Viewer shows the error:
Application Poole is being automatically disabled due to a series of failures in the processes serving that application Pool.
Currently there are no breakpoints added to DD and first chance exception is not enabled.
Are they really required to get the dump generated? Any special IIS Config required?
I'm on win 2003 with Debug Diag 1.2.
It has generated dumps in the past for memory but haven't seen any crash dumps so far.
Your help will be greatly appreciated, pleaseee guide.
Related
I am trying to debug high CPU usage in an IIS app pool on a Windows 2012 R2 server. I have installed DebugDiag v2 Update 3 and collected dumps of the IIS app pool whenever its CPU usage goes above a specified threshold.
I was able to get 11 dumps generated - 10 mini dumps and 1 full dump. However, when I open the DebugDiag Analysis tool and load any (or all) of the dump files and do a PerfAnalysis, it always fails with the error System.ArgumentException, no matter what I try. I have tried to do this multiple times, and I still get the same error every time I try to analyse the files.
Has anyone been able to successfully do a Perf Analysis? I tried the crash analysis and it seems to work fine; it's only the Perf Analysis which errors out.
Here is the kind of error I see every time I try to do a PerfAnalysis:
I need to debug a dll that's getting loaded on a specific application pool process. I'm using WinDbg, and so far I have successfully found the correct w3wp.exe process. Problem is, the app pool recycles itself, sometimes before it reaches what I want to find (a very elusive second chance exception). Then, I need to start over.
How do I configure WinDbg to automatically attach to a w3wp.exe process that's connected to a specific app pool, every time it starts?
Another solution would be to get the crash dump - I tried using ADPlus.exe for this but it also needs to be started on a process and I didn't find a way to re-run it automatically on only the process I need AND every time it starts.
So to sum it up, I need a way to get a crash dump from a w3wp.exe process that's connected to a specific IIS App Pool when it crashes on a second chance exception, while the process gets restarted once in a while (not enough time for me to run the debug tools manually each time).
Eventually, I discovered this awesome tool called DebugDiag, which is an official Microsoft tool. It has a nice interface that allows collecting dumps on certain events, such as exceptions, and creates very useful logs.
On top of that - it has a special section specifically for IIS debugging, which allowed me to select the app pool I was interested in.
Download available here.
i am creating a Windows CE 6.0 in Visual Studio 2005 with Platform builder. I integrated a stream device driver (via USB HID). I also have a small application that opens a connection to the device and reads data from it. When i build a Debug-Version of this Windows CE 6.0 and debug it on the device i can start the application and the communication to the device works fine. Now i build a Release-Version (no changes of Sources!) of the Windows CE 6.0, run it on the device and start the application on the device. When i try to read data from the device by ReadFile(), (i guess this calls XXX_Read() from the stream driver) my windows crashes and reboots. Its too bad, because i cant debug the CE where the windows exactly crashes... (because it does not crash in debug version ;).
What are the differences between Debug and Release Version of WinCE 6? Does anyone have a hint at which part of the Stream Device driver i need to have a closer look to solve this problem? I know that in Debug/Release the Project settings are not adopted. But i cant think of any setting that may influence the stream device driver.
Regards
The big difference between Release and Debug is that in a Debug build of code all variables get initialized to zero. In Release they do not get initialized at all and therefore often can end up with whatever non-zero garbage was in the storage location of the variable when it was allocated.
This is often a problem if you're creating pointers in your code and then checking them against NULL. A Debug build will tell you the pointer is NULL because it got initialized to zero. In Release it ends up non-zero, then you try dereferencing the garbage in the pointer and it causes an access violation crash.
The moral of the story: always, always initialize your variables in code. ZeroMemory/memset is your friend.
One thing you could do is to setup Dr. Watson so that you can generate a KDMP file when the crash occurs, then you can do a post-mortem debug analysis with the KDMP file to see where the crash is happening. See the docs to get more info on setting up Dr Watson on WinCE 6.0.
Once you have generated the crash dump file (*.KDMP), you can use Visual Studio 2005 to open the KDMP file (File | Open Project/Solution). Once it's loaded, use the Target | Attach device menu option to start the post-mortem debug session (Note that you are virtually "attaching" to the device via the KDMP file, you do not need to physically access the target device while post-mortem debugging)
You can also leave KITL and Kernel debugger enabled in your release image.
When you debug release code you will experience some strange behaviours (code not executed in order or multiple instructions executed in a single step, some variables can't be watched because they are stored into registers etc.), but you should be able to understand where your system crashes. If you have a watchdog this may be enabled only in release builds and that could explain the reboot.
For my work, I need to create a service that will detect an abnormal program termination and, instead of displaying a message to the user (default behavior), send the generated core dump to a remote server.
I'm pretty sure this can be done, but I have absolutely no clue on where to start. Is there any API/registry settings for this ?
Thank you.
One method is to install an Unhandled Exception Filter and then write a minidump from it which you can then upload to some place of your choosing. I wouldn't totally disregard Windows Error Reporting -- that's an addition to any crash reporting of your own. If your application is for public release then registering for Windows Error Reporting is well worthwhile as you get information about which crashes users are encountering in the wild and when crashes have been fixed you can add a response code to point them to a new version or other relevant information.
Another tool that may be useful depending on how your application is deployed in your organisation is to run Adplus on a user's machine which will collect together crash dumps. This is more useful for one-off crashes that seem to affect an individual user but aren't reproducible in a development environment.
Some other useful links:
http://www.debuginfo.com/articles/effminidumps.html - some useful sample code
http://www.codeproject.com/KB/debug/postmortemdebug_standalone1.aspx
It seems my question was either obvious or stupid (both ?) but anyway, i found some interesting pages after some researches.
Here are the links I found useful:
Track application crashes and disable Windows Error Reporting at the same time!
Disable error reporting
I am working on an ASP.NET web application, it seems to be working properly when I try to debug it in Visual Studio. However when I emulate heavy load, IIS crashes without any trace -- log entry in the system journal is very generic, "The World Wide Web Publishing service terminated unexpectedly. It has done this 4 time(s)."
How is it possible to get more information from IIS to troubleshoot this problem?
Download Debugging tools for Windows:
http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx
Debugging Tools for Windows has has a script (ADPLUS) that allows you to create dumps when a process CRASHES:
http://support.microsoft.com/kb/286350
The command should be something like (if you are using IIS6):
cscript adplus.vbs -crash -pn w3wp.exe
This command will attach the debugger to the worker process. When the crash occurs it will generate a dump (a *.DMP file).
You can open it in WinDBG (also included in the Debugging Tools for Windows). File > Open Crash dump...
By default, WinDBG will show you (next to the command line) the thread were the process crashed.
The first thing you need to do in WinDBG is to load the .NET Framework extensions:
.loadby sos mscorwks
then, you will display the managed callstack:
!clrstack
if the thread was not running managed code, then you'll need to check the native stack:
kpn 200
This should give you some ideas. To continue troubleshooting I recommend you read the following article:
http://msdn.microsoft.com/en-us/library/ms954594.aspx
Crash dump of asp.net process should give you tons of info..If you want to quickly get some info on why the process got recycled, try this tip from Scott Gu..
Health monitoring feature of asp.net 2.0 is also worth looking at..
The key is "without any trace". You need to put your own trace logging in to create some chatter. Then you'll be able to spot where the chatter stops.