When I'm running a program which is used to read an video I'm getting an error referring to Heapsize which is shown below:
EAP[videodemo34.exe]: Invalid address specified to RtlSizeHeap( 04EC0000, 00254CE8 )
Windows has triggered a breakpoint in videodemo34.exe.
This may be due to a corruption of the heap, and indicates a bug in videodemo34.exe or any of the DLLs it has loaded.
The output window may have more diagnostic information
can anyone say about it?
It would be helpful if you posted some code with your questions Prashanth (refer to one of your other threads).
Anyway it is doubtful that this is a bug as it clearly states that a breakpoint has been triggered in your code.
This will most likely be because you are running a debug executable with embedded breakpoints.
Related
Before some time i coded my own little db editor program, i was coding it from the zero using Win API's so its not very small project.
It was working fine on all OS till now, i have Win 7 x64 with all latest updates and my application is crashing with 0xC000005 exception because of some of the Heap functions(HeapAlloc or HeapFree, i use nothing else), i tried replacing HeapAlloc & HeapFree with VirtualAlloc and VirtualFree and it was all fine, but i dont want to use the virtual memory....
Something else, i tried to attach with debugger to trace the problem, but when i attach debugger its not crashing, then i tried to display MessageBox to trace where it crashes, but when i display MessageBox its not crashing too....
My application is running as 32bit process.
Coded in C.
Anyone had similar problem ?
Firstly, both HeapAlloc and VirtualAlloc allocate virtual memory.
My guess as to what is happening is that you are writing past the boundary of the allocated memory. The reason why this does not work with HeapAlloc is that it allocates exactly the amount of memory you request. With VirtualAlloc, the size returned is the requested size rounded up to the next page boundary. In your case, this gave a bit more leeway (even though your code is still doing the wrong thing).
In terms of why it has been working so far: you just got lucky. Look carefully at the code accessing the allocated memory and if you get stuck, post the relevant part up here. If the debugger isn't helping and the bug is easily reproducible, just comment out parts of the code until you locate the line causing the crash.
Have you attached it to Debug version of your application? If the problem does not appear in debug version then you should check what warnings (on highest level) generate your code, maybe you will find some uninitialized variables. If nothing here, then you might use some static analysis tool to help with finding bugs - like PVS-Studio http://www.viva64.com/.
You can also compile Release version with debugging information enabled, this way when problem arrises you should be able to attach to your application with debugger and see callstack with function names. To make it easier to debug, disable code optimizations.
You can also try gflags from windows debugger tools, this program will trigger breakpoint each time you write outside of buffer boundary. This is really helpfull tool because not all buffer overruns end up with exceptions. Use it on application with debugging information enabled, and preferably with code optimizations off. To enable gflags for your app use:
gflags /p /enable myapp.exe /full
(http://msdn.microsoft.com/en-us/library/windows/hardware/ff543097%28v=vs.85%29.aspx)
In Xcode 4.x I've edited my Run scheme to 'Enable Guard Malloc' since I have a nondescript malloc error I need to track down. I'm aware I need to run in the simulator to use this feature. However, when I do so the app immediately freezes and Xcode shows me a stack trace that looks like this:
I've googled around to find a solution, but thus far no joy. It was reported elsewhere that I should be setting an environment variable in my scheme:
DYLD_INSERT_LIBRARIES -> /usr/lib/libgmalloc.dylib
However this doesn't solve the problem. I have also tried 'lsystem' as the value, but that didn't work either.
Can anyone suggest a solution to this dylib issue, or perhaps recommend an alternative to 'Enable Guard Malloc' to identify where a malloc'd heap area is being exceeded?
UPDATE
To clarify, this is the type of error I'm dealing with:
malloc: *** error for object 0x2b4b54: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
I've tried setting a symbol breakpoint of malloc_error_break, however it still breaks 'randomly' upon memory issues rather than at the point of exceeding an allocated region.
To help with the debugging you can set MallocStackLogging, then when your App crashes, type this in the gdb console:
(gdb) info malloc-history 0x543216
Replace 0x543216 with the address of the object that caused the crash, and you will get a much more useful stack trace and it should help you pinpoint the exact line in your code that is causing the problem.
See this article for more detailed instructions.
I have a customer who is getting a 100% reproduceable crash that I can't replicate in my program compiled in Visual Studio 2005. I sent them a debug build of my program and kept all the PDB and DLL files handy. They sent me the minidump file, but when I open it I get:
"Unhandled exception at 0x00000000 in MiniDump.dmp: 0xC0000005: Access violation reading location 0x00000000."
Then the call stack shows only "0x00000000()" and the disassembly shows me a dump of the memory at 0x0. I've set up the symbol server, loaded my PDB symbols, etc. But I can't see any way of knowing which of the many DLLs actually caused the jump to null. This is a large project with many dependencies, and some of them are binaries that I don't have the source or PDBs for, as I am using an API as a 3rd party.
So how on earth is this minidump useful? How do I see which DLL caused the crash? I've never really used minidumps for debugging before, but all the tutorials I have read seem to at least display a function name or something else that gives you a clue in the call stack. I just get the one line pointing to null.
I also tried using "Depends" to see if there was some DLL dependency that was unresolved; however on my three test machines with various Windows OS's, I seem to get three different sets of OS DLL dependencies (and yet can't replicate the crash); so this doesn't seem a particularly reliable method either to diagnose the problem.
What other methods are available to determine the cause of this problem? Is there some way to step back one instruction to see which DLL jumped to null?
Well it looks like the answer in this instance was "Use WinDbg instead of Visual Studio for debugging minidumps". I couldn't get any useful info out of VS, but WinDbg gave me a wealth of info on the chain of function calls that led to the crash.
In this instance it still didn't help solve my problem, as all of the functions were in the 3rd party library I am using, so it looks like the only definitive answer to my specific problem is to use log files to trace the state of my application that leads to the crash.
I guess if anyone else sees a similar problem with an unhelpful call stack when debugging a minidump, the best practice is to open it with WinDgb rather than Visual Studio. Seems odd that the best tool for the job is the free Microsoft product, not the commerical one.
The other lesson here is probably "any program that uses a third party library needs to write a log file".
The whole idea behind all 'simple' ways of post mortem debugging is the capture of a stack trace. If your application overwrites the stack there is no way for such analysis. Only very sophisticated methods, that record the whole program execution in dedicated hardware could help.
The way to go in such a case are log files. Spread some log statements very wide around the area where the fault occurs and transmit that version to the customer. After the crash you'll see the last log statement in your log file. Add more log statements between that point and the next log statement that has not been recorded in the log file, ship that version again. Repeat until you found the line causing the problem.
I wrote a two part article about this at ddj.com:
About Log Files Part 1
About Log Files Part 2
Just an observation, but the the stack is getting truncated or over-written, might this be a simple case of using an uninitialised field, or perhaps a buffer overrun ?
That might be fairly easy to locate.
Have you tried to set WinDbg on a customer's computer and use it as a default debugger for any application that causes a crash? You just need to add pdb files to the folder where your application resides. When a crush happens WinDbg starts and you can try to get call stack.
Possibly you already know this, but here are some points about minidump debugging:
1. You need to have exactly the same executables and PDB files, as on the client computer where minidump was created, and they should be placed exactly in the same directories. Just rebuilding the same version doesn't help.
2. Debugger must be connected to MS Symbols server.
3. When debugger starts, it prints process loading log in the Output window. Generally, all libraries should be successfully loaded with debug information. Libraries without debug information are loaded as well, but "no debug info" is printed. Learn this log - it can give you some information.
If executable stack contains frames from a library without debug information, it may be not shown. This happens, for example, if your code is running as third-party library callback.
Try to create minidump on your own computer, by adding some code which creates unhandled exception, and debug it immediately. Does this work? Compare loading log in successful and unsuccessful debugging sessions.
You may have called null function pointer. Current executing function information is needed to show call stack information. Force set instruction pointer to start of any simple function, then you'll see call stack information again.
void SimpleFunc()
{ // <- set next statement here
}
Well, fortunately I haven't written many applications that cause a BSOD but I just wonder about the usefullness of the information on this screen. Does it contain any useful information that could help me to find the error in my code? If so, what do I need, exactly?
And then, the system restarts and probably has written some error log or other information to the system somewhere. Where is it, what does it contain and how do I use it to improve my code?
I did get a BSOD regularly in the past when I was interacting with a PBX system where the amount of documentation of it's drivers were just absent, so I had to do some trial-and-error coding. Fortunately, I now work for a different company and don't see any BSOD's as a result of my code.
If you want a fairly easy way to find out what caused an OS crash that will work ~90% of the time - assuming you have a crash dump available - then try the following:
Download WinDbg as part of the Debugging tools for Windows package. Note, you only need to install the component called Debugging Tools for Windows.
Run WinDbg
Select "Open Crash Dump" from the file menu
When the dump file has loaded type analyze -v and press enter
WinDbg will do an automated analysis of the crash and will provide a huge amount of information on the system state at the time of the crash. It will usually be able to tell you which module was at fault and what type of error caused the crash. You should also get a stack trace that may or may not be helpful to you.
Another useful command is kbwhich prints out a stack trace. In that list, look for a line contains .sys. This is normally the driver which caused the crash.
Note that you will have to configure symbols in WinDbg if you want the stack trace to give you function names. To do this:
Create a folder such as C:\symbols
In WinDbg, open File -> Symbol File Path
Add: SRV*C:\symbols*http://msdl.microsoft.com/download/symbols
This will cache symbol files from Microsoft's servers.
If the automated analysis is not sufficient then there are a variety of commands that WinDbg provides to enable you to work out exactly what was happening at the time of the crash. The help file is a good place to start in this scenario.
Generally speaking, you cannot cause a OS crash or bug check from within your application code. That said, if you are looking for general tips and stuff, I recommend the NTDebugging blog. Most of the stuff is way over my head.
What happens when the OS crashes is it will write a kernel dump file, depending on the current flags and so on, you get more or less info in it. You can load up the dump file in windbg or some other debugger. Windbg has the useful !analyze command, which will examine the dump file and give you hints on the bucket the crash fell into, and the possible culprits. Also check the windbg documentation on the general cause of the bug check, and what you can do to resolve it.
Every now and then (ahem...) my code crashes on some system; quite often, my users send screenshots of Windows crash dialogs. For instance, I recently received this:
Unhandled win32 exception # 0x3a009598 in launcher2g.exe:
0xC00000005: Access violation writing location 0x00000000.
It's clear to me (due to the 0xc0000005 code as well as the written out error message) that I'm following a null pointer somewhere in my launcher2g.exe process. What's not clear to me is the significance of the '0x3a009598' number. Is this the code offset in the process' address space where the assembler instruction is stored which triggered the problem?
Under the assumption that 0x3a000000 is the position where the launcher2g.exe module was loaded into the process, I used the Visual Studio debugger to check the assembler code at 0x3a009598 but unfortunately that was just lots of 'int 3' instructions (this was a debug build, so there's lots of int 3 padding).
I always wondered how to make the most of these # 0x12345678 numbers - it would be great if somebody here could shed some light on it, or share some pointers to further explanations.
UPDATE: In case anybody finds this question in the future, here's a very interesting read I found which explains how to make sense of error messages as the one I quoted above: Finding crash information using the MAP file.
0x3a009598 would be the address of the x86 instruction that caused the crash.
The EXE typically gets loaded at its preferred load address - usually 0x04000000 iirc. So its probably bloody far away from 0x3a009598. Some DLL loaded by the process is probably located at this address.
Crash dumps are usually the most useful way to debug this kind of thing if you can get your users to generate and send them. You can load them with Visual Studio 2005 and up and get automatic symbol resolution of system dlls.
Next up, the .map files produced by your build process should help you determine the offending function - assuming you do manage to figure out which exe/dll module the crash was inside, and what its actual load address was.
On XP users can use DrWatsn32 to produce and send you crash dumps. On Vista and up, Windows Error Reporting writes the crash dumps to c:\users\\AppData\Local\Temp*.mdmp