I made an console application in Visual c++ in VS 2010. I added the console handler so that when I press Ctrl+C the application may terminate successfully and it worked for me without error. Later I put the application into a window service and called the same console handler in service console handler in the following the cases SERVICE_CONTROL_STOP and SERVICE_CONTROL_SHUTDOWN. When I stop the service I get the error
HEAP CORRUPTION DETECTED:after Normal block(#119) at 0x003C5420.CRT detected that the application wrote to memory after end of heap buffer.`
What should I do to fix this?
You need to analyze dump files that are created after this failure.
So the first step is setup collecting dump files.
Then build your program in release mode with pdb-files and run it as windows
service.
Finally when you have dump files for this failure you can
use your debugger to analyze them. I often use for this purpose
WinDbg.
Related
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.
My winform application crashes as soon as its been launched. This problem is only happening in one of the client computer. Works fine for all other clients. I was thinking of using ADPlus to get a crash dump but problem is in order to configure ADPlus in crash mode, debugger need to be attached to running application first. That means application must be running when I configure ADPlus, however, as I said my application crashes as soon as I start it. It does not give me a chance to run ADPlus. Any idea if ADPlus can be used in this scenario? Are there any other tools that I can use generate a process dump in this case?
Since you can't start the program and then attach a debugger in time, you can try one of the following ideas:
Start the program under the debugger on the machine where it's crashing. As already mentioned, ProcDump is enough for that purpose, or you can use Visual Studio or WinDBG.
If you can't easily start the program under the debugger (for example, if it is actually a Windows service), use gflags to make Windows start the program under the debugger. This will create a subkey for your program filename under the Image File Execution Options registry key.
Set your debugger as the postmortem debugger, so it always launches when any program crashes.
If and when the crash happens, the debugger will automatically break in and either create a dump automatically or let you create one manually.
If you can't run a debugger, not even ProcDump, you can use Windows' built-in crash dump facility to create a dump automatically:
On Windows XP and Windows Server 2003, set Dr. Watson as the postmortem debugger by running this command:
drwtsn32 -i
Here is info on what this command does and how to use Dr. Watson: Capturing Application Crash Dumps
On Windows Vista SP1, Windows Server 2008, and later, set Windows Error Reporting to save dumps locally by creating this registry key:
HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps
You don't need to create or set any values or subkeys under this key. If you want to change settings, here is more info: Collecting User-Mode Dumps
Note that "applications that do their own custom crash reporting, including .NET applications, are not supported by" WER. This is a problem for you because your app uses WinForms - although there is some indication that the feature does work with .NET 4 apps on Windows 7.
You can use ProcDump from Sysinternals to capture a dump.
I am new to programming.
I know only Start debug before. Maybe start debug suit for some small application develop better.
I found Visual studio IDE provide another method of attach to process for using.
When & Why must I use the attach debugging?
Such as multi-threading application debugging. Client/Service application debugging. etc. Thank you.
Sometimes you need to debug a process started by another program.
For example you need a reliable solution and in order to protect against access violations, memory leaks and other barely recoverable stuff, you have a master program and several worker programs. The master program starts the worker program and passes parameters to it. How do you debug a worker program which is not intended to be started by anything except the master program?
You use "attach to process for that".
Typically you do it this way: insert a statement that blocks the worker program for some time - for example, call Sleep() for 15 seconds. Then you kindly ask the master program to start the worker program. When the worker program is started it blocks and you now have 15 seconds to attach to it.
This way you can debug almost any issues - problems at early startup stages, wrong parameters, etc, which you wouldn't reliably reproduce with "run with debugging".
Attaching to a process is useful if you don't want to debug right from starting the process. For example, debugging usually slows down execution, so it can be quicker to start the app, get it to a state where a bug appears, and then attach a debugger.
It's also useful if you already have an external means of launching the process that you don't want or can't to import into the IDE.
Start debugging from VS launches an instance of the VS webserver and attaches the debugger to it.
Attach to process allows you to attach to any process and debug it, usually you'd do this to your instance of w3wp.exe running your code in IIS
Attach to process is mostly used when you can't run the application from Visual Studio.
For example, if it's a service or if it is a process that has run for a long time and now you want to start debugging it.
Sometimes you also want to debug a remote process, not on your machine - and you can do that using attach to process.
I have a batch file which starts multiple instances of simple console application (Hello World!). I work on Windows server 2008 64-bit. I configure it to run in TaskScheduler, at startup, and whether user is logged-in or not. The later configuration means that the instances will run without GUI (i.e. - no window).
When I run this task, some of the instances just fail, after consuming 100& CPU. Application event-log shows the following error:
"Faulting module KERNEL32.dll, version 6.0.6002.18005, time stamp 0x49e0421d, exception code 0xc0000142, fault offset 0x00000000000b8fb8, process id 0x29bc, application start time 0x01cae17d94a61895."
Running the batch file directly works just fine. It seems to me that the OS has a problem loading too many instances of the application when no window is displayed. However - I can’t figure out why...
Any idea??
This issue has a fix, thanks to Microsoft expert:
http://social.msdn.microsoft.com/Forums/en/windowsgeneraldevelopmentissues/thread/9102531c-cf60-4682-b014-c11a190b00f1?prof=required
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.