I have an old application which calls GetOpenFileNameA and GetSaveFileNameA.
Both calls are erroneous. The application crashes!
I have used OllyDbg and API Monitor to read the size stored in the OPENFILENAME struct.
The size of the struct is 76 Bytes (testing with Windows 7 x64).
I get an access violation exception while GetOpenFileNameA or GetSaveFileNameA is called.
I assume that at runtime windows tries to read 88 Bytes instead of 76 Bytes.
Have a look at this:
http://dotnetbutchering.blogspot.de/2007/10/vc-60-getting-0xc0000005-access.html
and this
http://www.asmcommunity.net/board/index.php?topic=5768.15
I did some research and while doing that I have detected following behavior:
While running Microsoft Spy++ the application does not crash!!
I stepped through the debugger and I saw that the access violation exception still occurs but somehow the exception is swallowed.
The application works fine! I can load and save files.
I have the following ideas. What do you think about them?
write sth. like a Loader.exe which does the same like Spy++.
Swallowing the access violation exception when both APIs are called.
Use DLL Injection and API Hooking.
I could hook GetOpenFileName and GetSaveFileName with a custom implementation in a custom DLL. My implementation would fix the struct and pass the corrected struct to the original API calls.
Use SetWindowsHook to hook a window message ?!?!?!
Patch the binary file. Is it possible to fix this struct size issue by patching using a HEX Editor?
Which one would work?
Do you have a better idea how I can fix this?
I am not able to get the source code of this old application.
I have to fix it using the existing binaries.
My solution must work at least on Windows XP and Windows 7 (x86, x64)
The tool PEiD shows me following info about the old application:
Linker info: 2.55
MS Visual C++ 4.0
The size of the struct is 76 Bytes (testing with Windows 7 x64). I get
an access violation exception while GetOpenFileNameA or
GetSaveFileNameA is called. I assume that at runtime windows tries to
read 88 Bytes instead of 76 Bytes.
if you look at the OPENFILENAME struct you will notice a:
#if (_WIN32_WINNT >= 0x0500)
void * pvReserved;
DWORD dwReserved;
DWORD FlagsEx;
#endif // (_WIN32_WINNT >= 0x0500)
which in a 32bit program (VC++ 4 did not support 64bit targets) translates to exactly 12 bytes difference. As long as lStructSize is set properly by the caller, this should not be an issue at all. It may be worthwhile to use procdump from Microsoft/Sysinternals to get a minidump of the exact state (or attach a debugger and investigate). The exception you encounter does not necessarily have to be due to the struct size. If it is, it is more likely that Microsoft dropped the ball when it comes to backward compatibility of this function. Obviously OPENFILENAME::lStructSize is there for versioning of the struct and to ensure what you encounter wouldn't happen. But then, we're talking about a program built with a compiler/linker from times before Windows 2000.
write sth. like a Loader.exe which does the same like Spy++.
Swallowing the access violation exception when both APIs are called.
It's a fair point. If you would insert exception handling at the top level you could do things you want, but it may cause side-effects depending on what exactly caused the exception (i.e. which exact memory was overwritten).
Use DLL Injection and API Hooking. I could hook GetOpenFileName and
GetSaveFileName with a custom implementation in a custom DLL. My
implementation would fix the struct and pass the corrected struct to
the original API calls.
This is pretty much related to the first one. I think it will be easiest and safest in all, because this way you can correct the behavior without too much intrusion. Please read further below. Also, check out NInjectLib.
Use SetWindowsHook to hook a window message ?!?!?!
I don't see how that helps other than facilitating the injection of a DLL (for 1. and 2.).
Patch the binary file. Is it possible to fix this struct size issue by
patching using a HEX Editor?
This may be the trickiest, depending on whether the OPENFILENAME is inside the binary (initialized data) or on stack or whether it gets allocated on the heap (easy then).
One possible hybrid approach for 1. and 2. would be this:
Add a subkey to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options named after the program that you are executing (e.g. foo.exe)
Create a REG_SZ value named Debugger inside that newly-created subkey and set the value to a program that I will try to describe briefly now.
This effectively sets up a debugger for this old application of yours and it means that the debugger we're going to write will receive your application's command line as arguments. It is convenient, because it is transparent to the end-user and you can adjust it to suit your needs.
You'll need to write a debugger. This task isn't as taunting as it seems at first, because you can use the debugging helpers Win32 offers. The gist is in the debugger loop. In general you create the target process yourself using CreateProcess passing the appropriate flags to be able to debug it. The use WaitForDebugEvent and ContinueDebugEvent to control the execution. For all practical purposes you may not even need the debugger loop at all, because you could create the main thread of the target application suspended (pass CREATE_SUSPENDED to CreateProcess) and then point the CONTEXT of the main thread to your own code at the very beginning, then call ResumeThread(pi.hThread). This way you will be done before the main thread starts. However, this may cause issues due to the way kernel32.dll's CreateThread works (which involves registering the new thread with the Win32 subsystem aka csrss.exe). So it may be advisable to instead patch the IAT of the target in memory or something similar. After all you are merely interested in two functions.
Check out the two articles here and here for a more detailed look at the topic.
I for one prefer writing my debuggers based on PyDbg from PaiMei, but I have admittedly not tried to use such a Python-based debugger in Image File Execution Options.
(1) Would be pure hack which can be hard to do (what aspect of Spy++ behavior does it? Or you want to reinvent complete Syp++?), and even if you do that, how can you be sure the application will work correctly (for all input) after the 'swallowed exception'? Internal state of the program can be undefined and lead to other problems later.
(2) Assuming you don't have sources so you cannot fix it in a normal way, this IMHO seems the to be best work around of the issue.
(3) I can't see how this could help you.
(4) Possible but a lot of work probably. Assuming there are some data on the stack, then by resizing one of them (the OPENFILENAMEA struct) you move offsets of others so you will have to 'fix' references to those.
Related
As per the title, I can't locate any dump files when this program I support is crashing.
The application's logs clearly mention its a SIGSEGV exception, but I have searched my entire hard drive, and there are no .dmp files anywhere to be found.
The developers of the program have seen similar issues elsewhere but have so far been unable to explain why this is happening - and we're kind of a bit stuck at the moment.
The last section in the application logs reads as :
Received signal SIGSEGV, segmentation violation.
OurApplication::sigHandler 11.
Removing signal handlers.
OurApplication::signalCatched.
OurApplication::sigHandler: exiting application.
Removing signal handlers.
My limited understanding of this is that our application's signal handler might be 'neutralising' the SIGSEGV exception that got thrown. And therefore no core dump is getting generated... I did raise this idea with the developers but they never really seemed have investigated if this might be the reason. The theory they raised in counter was that they think the reason the dmp isn't getting generated is because the program may be crashing twice very close together.
So the questions I have at this point are:
Are there any Windows7 parameters that control the creation of a .dmp file?
Are there any requirements/flags that need to be compiled into a program in order for it (or windows) to create a core dump file if it crashes?
I'm 99% sure it must be windows that is responsible for creating the core file, since the program itself would be dead/terminated when it crashed, correct?
Are there any other things I should be aware of, or check for, or 'evidence' I can collect and then show our developers?
Many thanks in advance
Are there any Windows7 parameters that control the creation of a .dmp file?
There are parameters which control the creation of a crash dump: see MSDN on Collecting user-mode dumps.
Are there any requirements/flags that need to be compiled into a program in order for it (or windows) to create a core dump file if it crashes?
You don't need to compile anything in for the previous answer to work. However, the program needs to terminate due to an unhandled exception, which means you need to let the exception bubble up and not being handled by the unhandled exception handler.
I'm 99% sure it must be Windows that is responsible for creating the core file, since the program itself would be dead/terminated when it crashed, correct?
As stated above, Windows can handle that and it's a good idea to have Windows handle the crash. Imagine that your program is broken due to a memory leak. Some memory has been overwritten. In that case, your unhandled exception handler can be destroyed. Windows, however, still has full control over the process, can suspend it and create a dump from outside (rather from inside).
Are there any other things I should be aware of, or check for, or 'evidence' I can collect and then show our developers?
Well, suggest letting the dump be created by Windows due to above reasons. Then they also don't need to implement a configuration setting (you don't want the crash dump file to be always created, do you?). You don't need to implement a limiting number for the files. You don't need to implement a check for disk space, etc.
And you can suggest to read the Windows Internals 6 books.
Consider creating your own minidump file programatically. Should be plenty of code around showing how to do it. You can try here:
https://stackoverflow.com/search?q=minidump
This way, you're not relying on Dr. Watson or any other settings to create a dump file. Instead you will be calling the functions in DBGHELP.DLL to create the dump file.
I have a DX9 application that runs on an embedded Windows XP box. When leaving it automated overnight for soak testing it crashes after about six to eight hours. On our dev. machines (Win 7) we can't seem to reproduce this issue. I'm also fairly certain it's not a memory leak.
If we run the same application in Debug on the embedded machines, it doesn't crash.
If we place a __try/__except around the main loop update on the embedded machines, it doesn't crash.
I know in Debug, there is some additional byte padding around the local stack which may be "hiding" a local array access out of bounds, or some sort of uninitialized variable is sneaking through.
So I have two questions:
Does __try/__except behave similar to debug, even when run in release?
What kind of things should I be scanning the code for if we have a crash in Release mode, but not in Debug mode?
If you're using __try{ } __except() you shouldn't.
Those and C++ code don't mix well. (for instance, you can't have C++ objects on the stack of a function wrapped with those. You should use C++ try {} catch() {} if you use catch(...) (with ellipsis) it does basically the same as __except()
both try.. catch and __try .. __except behave the same in debug and release.
If you suspect that your problem is an unexpected exception you should read about all of the following:
SetUnhandledExceptionFilter()
_set_se_translator()
_CrtSetReportMode()
_RTC_SetErrorFunc()
_set_abort_behavior()
_set_error_mode()
_set_new_handler()
_set_new_mode()
_set_purecall_handler()
set_terminate()
set_unexpected()
_set_invalid_parameter_handler()
_controlfp()
Using one of the first two would probably allow you to pinpoint your problem pretty quickly. The rest are there if you want absolute control for all error cases possible in your process.
Specifically, with SetUnhandledExceptionFilter() you can set up a function filter which logs the address of the code which caused the exception. You can then use your debugger to pin point that code. Using the DbgHelp library and with the information given to the filter function you can write some code which prints out a full stack trace of the crash, including symbols and line numbers.
Make sure you set up your build configuration to emit debug symbols for release builds as well. They can only help and don't do anything to slow your application (but maybe make it bigger)
If we place a __try/__except around the main loop update on the embedded machines, it doesn't crash.
Then do that.
A single __try block around the whole program (as well as the entry point for each worker thread) is the recommended approach, it lets you write out a crash dump and make an error report before exiting. There's not much recovery you can do with SEH, because the exceptions just don't carry enough information to distinguish different failures usefully. Storing the whole program state and pulling it into a debugger is very useful, though.
Note: Some video drivers cause SEH exceptions that they also catch, perhaps some logic expects there to be more than one SEH scope installed, which your __try block provided.
I am profiling an application using VerySleepy 0.7. The application is written in C++ with Qt 4.6.x, compiled with VS 2005 and is running on Windows 7 Ultimate x64.
The highest usage by far is a call to RtlPcToFileHeader
Exclusive Inclusive %Exclusive %Inclusive Module
33.67s 33.67s 15.13% 15.13% ntdll
It is not clear to me from the documentation what RtlPcToFileHeader is but because it is referenced under "Error Handling Functions" it seems like it is something that should not be there. That being said, since it was used basically throughout my profiling capture, it could also be some very basic function call (i.e. something like main) or a side affect of the profiling itself.
What is the purpose of the RtlPcToFileHeader function?
Update: Based on Mike's suggestion, I did break into the running process and the couple times it included RtlPcToFileHeader in the stack trace it seemed somehow tied to a dynamic_cast. I have also changed to question to better reflect that I am trying to determine what RtlPcToFileHeader actually does.
The following MSDN post implies that Microsoft's x64 implementation of the RTTI routines, invoked during dynamic_cast, is slower than the x86 one.
http://blogs.msdn.com/b/junfeng/archive/2006/10/17/dynamic-cast-is-slow-in-x64.aspx
These RTTI pointers on 64-bit systems seem to be only offsets from the base address of the module. To dereference them, you need the module base address--which is retrieved by the API function ::RtlPcToFileHeader().
If this is correct, it seems that you can't do anything about it, except refactor your code to minimize the use of dynamic_casts and rely more on virtual methods. Or could it be only an imperfection of the profiler--it gets lost in dynamic_casts?
RtlPcToFileHeader is a function that uses an arbitrary address (PcValue) to look up a base address of the matching module mapped into the address space of the current process. It is very similar to calling:
HMODULE hModule = NULL;
GetModuleHandleEx(GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS |
GET_MODULE_HANDLE_EX_FLAG_UNCHANGED_REFCOUNT,
pArbitraryAddr,
&hModule);
For its search it goes through mapping addresses of all modules mapped into the current process, for which it uses the process' PEB/TEB structures in memory. Before doing that, it acquires a shared RW lock (similar to calling AcquireSRWLockShared) and then releases it when the search is done.
Just pause it under the debugger. Study the call stack to understand what it was doing and why. Then repeat several times. That will tell you where the time is going and the reasons why.
If that's too low-tech for you, try out LTProf, or any other wall-time stack sampler that reports line-level percent, preferably with a butterfly viewer.
The kind of numbers you are puzzling over is precisely the legacy of gprof.
I'm developing a game and when I do a specific action in the game, it crashes.
So I went debugging and I saw my application crashed at simple C++ statements like if, return, ... Each time when I re-run, it crashes randomly at one of 3 lines and it never succeeds.
line 1:
if (dynamic) { ... } // dynamic is a bool member of my class
line 2:
return m_Fixture; // a line of the Box2D physical engine. m_Fixture is a pointer.
line 3:
return m_Density; // The body of a simple getter for an integer.
I get no errors from the app nor the OS...
Are there hints, tips or tricks to debug more efficient and get known what is going on?
That's why I love Java...
Thanks
Random crashes like this are usually caused by stack corruption, since these are branching instructions and thus are sensitive to the condition of the stack. These are somewhat hard to track down, but you should run valgrind and examine the call stack on each crash to try and identify common functions that might be the root cause of the error.
Are there hints, tips or tricks to debug more efficient and get known what is going on?
Run game in debugger, on the point of crash, check values of all arguments. Either using visual studio watch window or using gdb. Using "call stack" check parent routines, try to think what could go wrong.
In suspicious(potentially related to crash) routines, consider dumping all arguments to stderr (if you're using libsdl or on *nixlike systems), or write a logfile, or send dupilcates of all error messages using (on Windows) OutputDebugString. This will make them visible in "output" window in visual studio or debugger. You can also write "traces" (log("function %s was called", __FUNCTION__))
If you can't debug immediately, produce core dumps on crash. On windows it can be done using MiniDumpWriteDump, on linux it is set somewhere in configuration variables. core dumps can be handled by debugger. I'm not sure if VS express can deal with them on Windows, but you still can debug them using WinDBG.
if crash happens within class, check *this argument. It could be invalid or zero.
If the bug is truly evil (elusive stack corruption in multithreaded app that leads to delayed crash), write custom memory manager, that will override new/delete, provide alternative to malloc(if your app for some reason uses it, which may be possible), AND that locks all unused memory memory using VirtualProtect (windows) or OS-specific alternative. In this case all potentially dangerous operation will crash app instantly, which will allow you to debug the problem (if you have Just-In-Time debugger) and instantly find dangerous routine. I prefer such "custom memory manager" to boundschecker and such - since in my experience it was more useful. As an alternative you could try to use valgrind, which is available on linux only. Note, that if your app very frequently allocates memory, you'll need a large amount of RAM in order to be able to lock every unused memory block (because in order to be locked, block should be PAGE_SIZE bytes big).
In areas where you need sanity check either use ASSERT, or (IMO better solution) write a routine that will crash the application (by throwing an std::exception with a meaningful message) if some condition isn't met.
If you've identified a problematic routine, walk through it using debugger's step into/step over. Watch the arguments.
If you've identified a problematic routine, but can't directly debug it for whatever reason, after every statement within that routine, dump all variables into stderr or logfile (fprintf or iostreams - your choice). Then analyze outputs and think how it could have happened. Make sure to flush logfile after every write, or you might miss the data right before the crash.
In general you should be happy that app crashes somewhere. Crash means a bug you can quickly find using debugger and exterminate. Bugs that don't crash the program are much more difficult (example of truly complex bug: given 100000 values of input, after few hundreds of manipulations with values, among thousands of outputs, app produces 1 absolutely incorrect result, which shouldn't have happened at all)
That's why I love Java...
Excuse me, if you can't deal with language, it is entirely your fault. If you can't handle the tool, either pick another one or improve your skill. It is possible to make game in java, by the way.
These are mostly due to stack corruption, but heap corruption can also affect programs in this way.
stack corruption occurs most of the time because of "off by one errors".
heap corruption occurs because of new/delete not being handled carefully, like double delete.
Basically what happens is that the overflow/corruption overwrites an important instruction, then much much later on, when you try to execute the instruction, it will crash.
I generally like to take a second to step back and think through the code, trying to catch any logic errors.
You might try commenting out different parts of the code and seeing if it affects how the program is compiled.
Besides those two things you could try using a debugger like Visual Studio or Eclipse etc...
Lastly you could try to post your code and the error you are getting on a website with a community that knows programming and could help you work through the error (read: stackoverflow)
Crashes / Seg faults usually happen when you access a memory location that it is not allowed to access, or you attempt to access a memory location in a way that is not allowed (for example, attempting to write to a read-only location).
There are many memory analyzer tools, for example I use Valgrind which is really great in telling what the issue is (not only the line number, but also what's causing the crash).
There are no simple C++ statements. An if is only as simple as the condition you evaluate. A return is only as simple as the expression you return.
You should use a debugger and/or post some of the crashing code. Can't be of much use with "my app crashed" as information.
I had problems like this before. I was trying to refresh the GUI from different threads.
If the if statements involve dereferencing pointers, you're almost certainly corrupting the stack (this explains why an innocent return 0 would crash...)
This can happen, for instance, by going out of bounds in an array (you should be using std::vector!), trying to strcpy a char[]-based string missing the ending '\0' (you should be using std::string!), passing a bad size to memcpy (you should be using copy-constructors!), etc.
Try to figure out a way to reproduce it reliably, then place a watch on the corrupted pointer. Run through the code line-by-line until you find the very line that corrupts the pointer.
Look at the disassembly. Almost any C/C++ debugger will be happy to show you the machine code and the registers where the program crashed. The registers include the Instruction Pointer (EIP or RIP on x86/x64) which is where the program was when it stopped. The other registers usually have memory addresses or data. If the memory address is 0 or a bad pointer, there is your problem.
Then you just have to work backward to find out how it got that way. Hardware breakpoints on memory changes are very helpful here.
On a Linux/BSD/Mac, using GDB's scripting features can help a lot here. You can script things so that after the breakpoint is hit 20 times it enables a hardware watch on the address of array element 17. Etc.
You can also write debugging into your program. Use the assert() function. Everywhere!
Use assert to check the arguments to every function. Use assert to check the state of every object before you exit the function. In a game, assert that the player is on the map, that the player has health between 0 and 100, assert everything that you can think of. For complicated objects write verify() or validate() functions into the object itself that checks everything about it and then call those from an assert().
Another way to write in debugging is to have the program use signal() in Linux or asm int 3 in Windows to break into the debugger from the program. Then you can write temporary code into the program to check if it is on iteration 1117321 of the main loop. That can be useful if the bug always happens at 1117322. The program will execute much faster this way than to use a debugger breakpoint.
some tips :
- run your application under a debugger, with the symbol files (PDB) together.
- How to set Visual Studio as the default post-mortem debugger?
- set default debugger for WinDbg Just-in-time Debugging
- check memory allocations Overriding new and delete, and Overriding malloc and free
One other trick: turn off code optimization and see if the crash points make more sense. Optimization is allowed to float little bits of your code to surprising places; mapping that back to source code lines can be less than perfect.
Check pointers. At a guess, you're dereferencing a null pointer.
I've found 'random' crashes when there are some reference to a deleted object. As the memory is not necessarily overwritten, in many cases you don't notice it and the program works correctly, and than crashes after the memory was updated and is not valid anymore.
JUST FOR DEBUGGING PURPOSES, try commenting out some suspicious 'deletes'. Then, if it doesn't crash anymore, there you are.
use the GNU Debugger
Refactoring.
Scan all the code, make it clearer if not clear at first read, try to understand what you wrote and immediately fix what seems incorrect.
You'll certainly discover the problem(s) this way and fix a lot of other problems too.
My application crashes after running for around 18 hours. I am not able to debug the point in the code where it actually crashes. I checked the call stack- it does not provide any information as such. The last few calls in the call stack are greyed out-meaning I cannot see the code of that part-they all belong to MFC libraries.
However, I get this 'MicroSoft Visual Studio' pop-up when it crashes which says :
Unhandled exception at 0x7c809e8a in NIMCAsst.exe: 0xC0000005:
Access violation reading location 0x154c6000.
Could the above information be useful to understand where it is crashing.Is there any software that could tell me a particular memory address is held by which variable in the code.
If you can't catch the exception sometimes you just have to go through your code line by line, very unpleasant but I'd put money on it being your code not in MFC (always is with my bugs). Check how you're using memory and what you're passing into the MFC functions extra carefully.
Probably the crash is caused by a buffer overflow or other type of memory corruption. This has overwritten some part of the stack holding the return address which has made the debugger unable to reconstruct the stack trace correctly. Or, that the code that caused the crash, you do not have correct sybols for (if the stack trace shows a module name, this would be the case).
My first guess would be to examine the code calling the code that crashed for possible issues that might have caused it. Do you get any other exceptions or error conditions before the crash? Maybe you are ignoring an error return? Did you try using the Debug Heap? What about adplus? Application verifier to turn on heap checks?
Other possibilities include to run a tool like pclint over the code to check for obvious issues of memory use. Are you using threads? Maybe there is a race condition. The list could go on forever really.
The above information only tells you which memory was accessed illegally.
You can use exception handling to narrow down the place where the problem occurs, but then you need at least an idea in which corner to seek.
You say that you're seeing the call stack, that suggests you're using a debugger. The source code of MFC is available (but perhaps not with all vc++ editions), so in principle one can trace through it. Which VC++ version are you using?
The fact that the bug takes so long to occur suggests that it is memory corruption. Some other function writes to a location that it doesn't own. This works a long time, but finally the function alters a pointer that MCF needs, and after a while MFC accesses the pointer and you are notified.
Sometimes, the 'location' can be recognized as data, in which case you have a hint. F.e. if the error said:
Access violation reading location 0x31323334
you'd recognize this as a part of an ASCII string "1234", and this might lead you to the culprit.
As Patrick says, it's almost definitely your code giving MFC invalid values. One guess would be you're passing in an incorrect length so the library is reading too far. But there are really a multitude of possible causes.
Is the crash clearly reproducible?
If yes, Use Logfiles! You should use a logfile and add a number statements that just log the source file/line number passed. Start with a few statements at the entrypoint (main event handler) and the most common execution paths. After the crash inspect the last entry in the logfile. Then add new entries down the path/paths that must have been passed etc. Usually after a few iterations of this work you will find the point of failure. In case of your long wait time the log file might become huge and each iteration will take another 18 hours. You may need to add some technique of rotating log files etc. But with this technique i was able to find some comparable bugs.
Some more questions:
Is your app multithreaded?
Does it use any arrays not managed by stl or comparable containers (does it use C-Strings, C/C++-Arrays etc)?
Try attaching a debugger to the process and have the debugger break on access violations.
If this isnt possible then we use a tool called "User mode process dumper" to create a memory dump of the process at the point where the access violation happened. You can find this for download here:
http://www.microsoft.com/downloads/details.aspx?FamilyID=E089CA41-6A87-40C8-BF69-28AC08570B7E&displaylang=en
How it works: You configure rules on a per-process (or optionally system-wide) basis, and have the tool create either a minidump or a full dump at the point where it detects any one of a list of exceptions - one of them being an access violation. After the dump has been made the application continues as normal (and so if the access violation is unhandled, you will then see this dialog).
Note that ALL access violations in your process are captured - even those that are then later handled, also a full dump can create a while to create depending on the amount of memory the application is using (10-20 seconds for a process consuming 100-200 MB of private memory). For this reason it's probably not a good idea to enable it system-wide.
You should then be able to analyse the dump using tools like WinDbg (http://www.microsoft.com/whdc/devtools/debugging/default.mspx) to figure out what happened - in most cases you will find that you only need a minidump, not a full dump (however if your application doesnt use much memory then there arent really many drawbacks of having a full dump other than the size of the dump and the time it takes to create the dump).
Finally, be warned that debugging access violations using WinDbg can be a fairly involed and complex process - if you can get a stack trace another way then you might want to try that first.
This is the cause of possible memory leak, there are various blogs could teach on checking for memory leaks in application, you simply make observations on Physical Memory of the process from Windows Task Manager, you could find at some stage where memory keep increasing & run out of memory. You can also try running with windbg tool to identify memory leaks in your code. I havent used this tool just giving some heads up on this.
This question is pretty old, and I've had the same problem,
but I've quickly solved it - it's all about threads:
First, note that updating GUI can only be done at the Main Thread.
My problem was that I've tried to handle GUI from a Worker Thread (and not a Main Thread) and i've got the same error: 0xC0000005.
I've solved it by posting a message (which is executed at the Main Thread) - and the problem was solved:
typedef enum {
WM_UPDATE_GUI
}WM_MY_MSG
// register function callback to a message
BEGIN_MESSAGE_MAP(CMyDlg, CDlgBase)
ON_MESSAGE(WM_UPDATE_GUI, OnUpdateGui)
END_MESSAGE_MAP()
// For this example - function that is not invoked in the Main Thread:
void CMyDlg::OnTimer()
{
CString str_to_GUI("send me to gui"); // send string to gui
// Update_GUI(str_to_GUI); // crashed
::PostMessage(hWnd, MyMsg::WM_UPDATE_GUI, (WPARAM)&str_to_GUI, 0);
}
HRESULT CMyDlg::OnUpdateGui(WPARAM wParam, LPARAM lParam)
{
CString str = *(CString*)wParam; // get the string from the posted message
Update_GUI(str);
return S_OK;
}