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)
Related
I am working on an application that when compiled in debug mode for Win32 (on a x64 machine), just before exiting, throws this exception:
From what I was able to reconstruct, it seems that the offending line of code is this, in the xmemroy0.h header:
// If the following asserts, it likely means that we are performing
// an aligned delete on memory coming from an unaligned allocation.
_STL_ASSERT(_Ptr_user[-2] == _Big_allocation_sentinel, "invalid argument");
It seems that this happens when a dll of mine (which is part of the application) is unloaded by the SO. It doesn't seem to be a directly a problem of my software, but I fear I could be the indirect cause of the problem by not handling correctly the dll boilerplate code. For example I am doing nothing special to handle attachments/detachments in the dll. What seems wired to me is that the x64 version seems to work just fine.
Any clue from a senior system programmer that could point me in the right direction would be highly appreciated. I don't really know how to debug this, I am not an expert of the Windows internals.
Sincerely,
I have been struggling to detect a memory corruption error in our product. The memory detection tools like valgrind only tell the problem at the time of the crash, not when the corruption actually occurs. I have seen while using debug builds that it will check the memory area before and after the block being freed, and show a debug assertion failure saying a heap corruption has occured. So can I rebuild my product in debug mode to capture the error right when it occurs? Will it also catch buffer overruns etc? I could not find any information on the internet about debug builds being targetted towards memory error detection.
You can use as well the 'Page Heap' available on every version of Windows.
You can use gflags that comes along to Debugging Tools for Windows to configure Full Page Heap for your application.
You can then run your application, even in retail mode, under the debugger. The debugger will stop once you encounter a buffer overrun or access to freed memory.
I like very much this tool, because it is built in the OS, an can even be activated on a customer site (gflags only sets registry keys and you can simply send these keys to your customer).
Some people are afraid when we mention (Debugging Tools for Windows). You can use Visual Studio to diagnose the problem. The only thing you need are the PDBs corresponding to your binaries (you can generate them even for release builds).
I am not sure about the debug builds, but for a nice overview of memory corruption tools you might look at http://code.google.com/p/address-sanitizer/wiki/ComparisonOfMemoryTools. It list Valgrind and what it should be able to check for you.
"C++" is not a compiler; vendors make their own according (more or less) to the standard specs.
I only have experience with Microsoft's, and I can tell you that it checks heap corruption by allocating "sentries" around each new or malloc block (in debug mode only, of course) and filling them with a special pattern (was 0xCD when I last used it), and then it checks the guards for every write around that location. If they changed, you'll get a run-time error saying the heap got corrupted.
By the way, buffer overflows are heap corruption.
Edit to add a reference: http://msdn.microsoft.com/en-us/library/8wtf2dfz.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)
Good Morning everyone
I'm currently facing a segfault at random on a little piece of software, however, It appears only when not started with an attached debugger (due to a possible memory error, where values are initialized in a safe interval when started with a debugger).
Is it possible to attach an debugger only in case of an segfault, just-in-time, like, for example attaching Visual Studio to a process when unhanded exceptions happen in Windows?
I am working on Ubuntu, 32 bit.
thanks in advance
Out of the box, Ubuntu limits the core file size to "none". Changing it with ulimit -c unlimited will allow your errant program to dump core like it should and then GDB will be happy to allow post-mortem analysis of the fault.
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