I have been battling a crash that occurs in my game engine for about 6 months now. I have recently received a few memory dumps from a tester who gets the crashes (I don't get them myself). The tester is on Windows 7 32 bit, and I am on Windows Xp 32 bit. The crashes seem to be related to Sapi, the text-to-speech part to be more exact. I am calling it via the IDispatch interface, using the wrapper found at:
http://www.morearty.com/code/dispatch/
Here are two stack traces extracted from two memory dumps.
http://www.blastbay.com/analysis1.txt
http://www.blastbay.com/analysis2.txt
The crash shown in the first stack trace occurred at random during the game's execution as it seems, and for some reason the entire stack is not resolved even though perilous_hearts.pdb is certainly present. In the second trace, it is finding the perilous_hearts symbols just fine. I am completely clueless as to what this error might be caused by. Can anyone give me some hints?
As I mentioned before, these crashes do not occur on Windows XP but only on Windows 7, both being 32 bit machines.
In both cases that crash is caused by hlas.dll, whatever that is. As the analysis says, you have heap corruption in the first stack, and a null pointer function pointer in the second. Hlas is also present in your other question about crashes in this same program.
Related
Ive got an issue using RFT with VB6 on Win7 (32,64) bit. This isnt is not present on Windows XP.
I am unable to highlight objects, or call verification points as the VB6 application crashes with a stackhash error. I have done weeks of research and have tried various things(DEP, Compatibility mode, clean boots etc) but am thus far unable to isolate the issue.
It seems that certain properties, these can vary, are not available once the program has been compiled. Running the application through VB6 IDE in debug mode does not result in a crash. Once compiled though, the crash occurs constantly.
I have used Windbg to debug the error to see what happens, and can see that there is a call to unallocated memory, resulting in heap corruption. What causes this? Is there anyway around this?
Any help would be appreciated :)
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)
I wrote some program which uses information about (reads via Windows) hardware of the current PC (big program, so I can't post here code) and sometimes my windows 7 crashes, the worst thing is that I have no idea why, and debug doesn't help me, is there any way to receive from windows 7 some kind of log, why it crashed? thanks in advance for any help
The correct (but somewhat ugly) answer:
Go to Computer->Properties, go to 'Advanced System Settings'.
Under startup and recovery, make sure it is set to "Kernel memory dump" and note the location of the dump file (on a completely default install, you are looking at C:\windows\memory.dmp)
You optimally want to install Windows Debugging tools (now in the Windows SDK) as well as setting the MS Symbol store in your symbol settings (http://msdn.microsoft.com/en-us/library/ff552208(v=vs.85).aspx)
Once youv'e done all that, wait for a crash and inspect memory.dmp in the debugger. Usually you will not see the exact crash because your driver vendors don't include symbols, but you will also generally get to see the DLL name that is involved in the crash, which should point you to what driver you are dealing with.
If you are not seeing a specific driver DLL name in the stack, it often indicates to me a hardware failure (like memory or overhead) that needs to be addressed.
MS has a good article here at technet that describes what I mentioned above (but step by step and in greater detail) http://blogs.technet.com/b/askcore/archive/2008/11/01/how-to-debug-kernel-mode-blue-screen-crashes-for-beginners.aspx
You can also look at the event log as someone else noted, but generally the information there is next to useless, beyond the actual kernel message (which can sometimes vaguely indicate whether the problem is driver or something else)
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
Related to this question. Any advice on fixing the problem below?
After a lot of experimentation with the program, I have discovered several things.
It crashes relatively consistently (90% of the time or so) upon running the line of code, Set Message = New CAPICOM.EncryptedData. Note that the line above this is merely Dim Message As CAPICOM.EncryptedData.
The function that makes that call does not crash when called earlier in the program's execution. Binary search for error does not work to find the problem, since calling the function in some places mysteriously, unreliably prevents the bug from happening. Sometimes rebuilding the program seems to impact if the bug shows up. Yes, it is a heisenbug. The same issues apply with temporal binary search for error. Spending 5 hours comparing two versions of the program only to discover that both versions have the bug even though only one of them is currently showing the symptoms is not very productive.
The crash is due to an access violation 0xC00000005
Running WinDbg (the windows debugger) shows that there is only one line of code which reads this memory location, LoadPicture(szTmpBMP). It is called at the end of a scary function which grabs the picture out of a resource and sticks it in a temp file. I was scared enough of this function that, for the sake of testing, I replaced it with a call to LoadPicture("testcra.bmp"), then didn't call the scary resource function for that bitmap. This did not help. Removing this call to loadpicture entirely also did not help, though the debugger could no longer find any points where the affected memory was being read, and the affected memory was no longer at the same location. This testing was done on a VM, so some memory reads are not necessarily going to be visible to the debugger.
Everything works perfectly on Vista (both my local machine and a Vista VM). The access violation only occurs on XP.
I'm using VB6 Version 8176, 6.0.8169
My current solution, which works, is to create all my capicom objects early, and never to create new instances of capicom.encrypteddata beyond the first. This works, but it is unlikely that the underlying problem was actually fixed.