I am building up a program and it works fine past few days. When I run it today it shows this Unhandled exception at 0x7770efc8 in LHM.exe: 0xC0000005: Access violation writing location 0x00440f48.
ntdl.dll!7770fb12()
In the call stack below, it indicates that frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll.
And I found the ntdl.dll!7770fb12() is 7770FB12 push esi in the Disassembly.
Is there anyway I can solve this problem?
Even if the call stack doesn't show any specific location with a call in your code eventually leading to ntdll.dll, in most cases you can pinpoint the call by stepping through your code from the beginning. If your code is too big, try to set breakpoints randomly and narrow it down continuously.
This is some very basic and maybe crude debugging procedure but it helps me alot...
'Frames below may be incorrect' is definitely not a sign of corrupted stack. It is easily solvable if you load the public symbols for ntdll from MS servers (done easily from the IDE - say, right click ntdll at the 'modules' window).
A deeper dive is available here.
Related
I've got a crash minidump to analyze. My program is multithread Qt5 application. I'm not a debugging guru but usualy I can easily find place where program failed, but this time I can't. I opened dump file in Visual Studio 2010, clicked "Debug with native only" and it shows me where problem is: it is thread with location "__CxxUnhandledExceptionFilter". Call stack is like this:
msvcr100.dll()!_abort()
msvcr100.dll()!terminate()
program.exe!__CxxUnhandledExceptionFilter(_EXCEPTION_POINTERS * pPtrs)
KERNELBASE.dll!_UnhandledExceptionFilter()
ntdll.dll!__RtlUserThreadStart()
ntdll.dll!__RtlUserThreadStart()
I expected to see stack with program functions and Qt internal functions. But this call stack tells me nothing interesting. So please tell me what is the "ExceptionFilter"-thread and how can I find place where program failed actually?
You are viewing the application at the point where the unhandled exception has already been caught by the default exception filter.
That is, you are not seeing the line where the exception occurred.
Unfortunately, this means the minidump likely contains no useful information.
You might try inspecting the _EXCEPTION_POINTERS structs, it might contain the EIP of the instruction that triggered the unhandled exception.
See the value of pPtrs->ExceptionRecord->ExceptionAddress, that should hold the EIP.
From MSDN:
ExceptionAddress: The address where the exception occurred.
To get the stack trace at the point where the exception occured, read http://support.microsoft.com/kb/313109.
In a process to migrated an existing 32 bit MFC Code to 64 bit, I did a successful build and tried to test the code
Unfortunately while testing the process seems to fail (rather crash) in
Failing Stack
hWnd = ::CreateDialogIndirect(hInst, lpDialogTemplate, pParentWnd->GetSafeHwnd(), AfxDlgProc);
CreateDlgIndirect(lpDialogTemplate, CWnd::FromHandle(hWndParent), hInst)
CDialog::DoModal()
No Dump is generated nor the generated exception is getting caught by SEH
I tried comparing the debug run with an existing working Win32 debug run but could not find any significant differences
At this moment I am clueless how I should proceed. Any sort of help is highly anticipated
Exception Info:
First-chance exception at 0x000007fefd89a5ed (KernelBase.dll) in xyz.exe: 0x00001234: 0x1234.
Actual Problem
The Actual Problem was due to pointer truncation that was happening causing it to crash. #OwenWengered's solution did help me to pinpoint the issue and to deal with all such pointer truncation which I am currently working. Which me luck :-)
Just as HansPassant already said in the comments, there's little you can do other than debugging it and tracing what actually the application tried to do at that time.
For complete start, the "0x1234" value seems very odd. If you have sources, find the offending line and set breakpoint there. Then, once hit, check which of the values (hinst? lpdialogtemplate? pParentWnd?) might have been trimmed to that 0x1234. It is possible that in your debug session the value 1234 will be different, so be careful and check any pointers that look odd, ie. are too small or seem unaligned.
If you have sources, post the relevant parts around (before!) that call you quoted.
If you don't have any sources, try to get them :)
If you can't get them, then you can debug in raw (dis)assembly, but then, you'd need to quote not only the asm parts, but also register and stack values.. and well, it will be hard to get audience probabaly.
It's hard to say anything more, as currently I/we know even less about your case than you :)
I just had a very similar issue. Along time ago when coding in VS6 you were able to create a manifest file (under resources) to change the look of your dialogs to give them an WinXP dialog look (with rounded edges).
https://msdn.microsoft.com/en-us/library/aa289524%28v=vs.71%29.aspx
So I had a file called IDR_WIN_XP_THEME under RT_MANIFEST in Resources.
I was able to upgrade to all versions of Visual Studio. But when I converted the app to 64 bits in VS2015 and tried to open the application in 64 bits it failed with an exception error.
Exception thrown at 0x000007FEFC94965D (KernelBase.dll)
I just deleted the IDR_WIN_XP_THEME manifest file and it started working.
Alright, I presented this question on the MSDN forums but have yet to receive any kind of response so I figured I'd give StackOverflow a try.
I'm currently developing a DirectX application using VS2008 on Win7. I recently experienced a nasty memory corruption bug with a memory allocation class that grabbed byte aligned memory. During this bug I could still run the debug and release executables however it would crash due the instructions getting corrupted or whatever, but it would still execute for a bit until the crash.
I then stripped out the entire memory allocation class. The application runs perfectly in the IDE (release and debug builds) but I can't run any of the executables at all. They immediately crash with a non-responding/stop working error. And I don't think it is my environment because I get the same issue on another computer that wasn't having problems before either.
Dependency walker gives a "Warning: At least one delay-load dependency module was not found. Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module." error and indicates that GPSVC.dll and IESHIMS.DLL can't be found. I've read that this can be misleading and just indicates a potential problem somewhere. And Dependency walker wasn't giving me this error the day before.
I haven't tinkered with any of the configuration or project settings or added new code. Any idea of what could be causing this behavior?
Also another note, I installed the Windows 7.1 sdk the same day. Think this could be some kind of compiler related bug?
Just in case some useful information pops up on the MSDN post, here is the link
http://social.msdn.microsoft.com/Forums/en-IE/vsdebug/thread/f692b394-8af2-4453-991c-aa6a443a9019
Thanks!
Edit -
Here is the last couple lines of Dependency Walker's profiling output
GetProcAddress(0x76CD0000 [c:\windows\syswow64\KERNEL32.DLL], "DecodePointer") called from "c:\windows\syswow64\NVWGF2UM.DLL" at address 0x6D8BAE4F and returned 0x77B59D65.
GetProcAddress(0x76CD0000 [c:\windows\syswow64\KERNEL32.DLL], "DecodePointer") called from "c:\windows\syswow64\NVWGF2UM.DLL" at address 0x6D8BAE4F and returned 0x77B59D65.
GetProcAddress(0x76CD0000 [c:\windows\syswow64\KERNEL32.DLL], "EncodePointer") called from "c:\windows\syswow64\NVWGF2UM.DLL" at address 0x6D8BAF60 and returned 0x77B60FDB.
GetProcAddress(0x76CD0000 [c:\windows\syswow64\KERNEL32.DLL], "DecodePointer") called from "c:\windows\syswow64\NVWGF2UM.DLL" at address 0x6D8BAF70 and returned 0x77B59D65.
Second chance exception 0xC0000005 (Access Violation) occurred in "c:\users\joel\desktop\DXAPP.EXE" at address 0x0110152E.
Exited "c:\users\joel\desktop\DXAPP.EXE" (process 0x27D8) with code 255 (0xFF).
Is this referring to a DLL grabbing a null pointer or to my actual instructions? Going to read up on how to use WinDbg real quick and I'll post it's output if this doesn't shed any immediate light on the issue.
Edit 2 -
Simply running the application and hitting debug to bring up Visual Studio consistently brought me to where I'm compiling my shaders. I'm assuming at the moment that the root of the problem lies around this. However, I still don't understand the change of behavior during execution between using the IDE and not.
Solution! -
I was so thrown off by the previous memory corruption bug that I didn't realize my shaders weren't in a local directory to the executables. This in turn was generating a null pointer that wasn't handled properly after calling D3DX11CompileFromFile().
Shoot, sorry I meant to post this as a comment...
I can only suggest more diagnostic attempts.
One would be to profile the app from within Depends, this will also show dynamic DLL loads and might show something new. Also it captures the debug output. It may behave differently than launching in the debugger itself and provide a clue. You don't mention actually profiling so I thought I'd suggest it in case you hadn't. Also, pay very close attention to the paths for the DLL's loaded - you might be surprised at a DLL loading from a location other than you intended.
Another suggestion is to try at attach to the stopped app after the crash (before dismissing the error dialog). See if you can get a stack trace or anything out of it.
Finally try attaching (or even launching from) WindDbg rather than the IDE. Like the Depends profile, the difference in debugger behavior and how it hooks the app may allow the crash to happen, while providing the clues you need.
Good Luck!
Here's the situation:
Background
I have a mixed mode .NET/Native application developed in Visual Studio 2008.
What I mean by mixed mode is that the front end is written in C++ .NET which calls into a native C++ library. The native code does the bulk of the work in the app, including kicking off new threads as it requires. The .NET code is just for UI purposes (win forms).
I have a release build of application running on a tester's computer.
The native libraries were compiled with full optimisations but also with debugging enabled (the "Debug Information Format" was set to "Program Database").
What this means is that I have the debugging symbols for the application in a PDB file.
The problem
So anyway, one of the testers is having a problem with the app where it occasionally crashes on XP. I've been able to get the minidump of the crash using Dr Watson for several runs.
When I debug into it (using the minidump - I'm not actually debugging the real app), all the debugging symbols are loaded correctly: I can see the full stack trace of all of the native threads correctly. Other threads (which are presumably the .NET threads) don't have a stack trace, but they all at least show me which dll the thread was started on (i.e. ntdll.dll).
It correctly reports the thread which fails ("Unhandled exception at 0x0563d652 in user(5).dmp: 0xC0000005: Access violation reading location 0x00000000).
However when I go into the thread it shows nothing useful. In the stack trace there is a single entry which just has the memory address "0563d652()" (not even "ntldll.dll").
When I go into dissasembly it just shows a random section of about 30 instructions. Either side of the memory address is just "???". It almost looks like it is not part of my source code (isn't your binary loaded sequentially into memory? is it normal to have a random set of assembly statements in the middle of nowhere?).
My questions
So basically my questions are threfold.
1) Can anyone explain the debugger's lack of information?
2) Bearing in mind, I can't show the error occurred in my code, can anyone suggest a reason for the failure
3) Can I do anything else to help me diagnose this current problem in the future?
Help!
John
Update:
Here is the stack dump for the failing thread from WinDBG
# ChildEBP RetAddr
WARNING: Frame IP not in any known module. Following frames may be wrong.
00 099bf414 02d0e7fc 0x563d652
01 00000000 00000000 0x2d0e7fc
Weird huh? Doesn't even show a DLL.
Is it possible that I've corrupted the stack/heap somehow which has caused a thread to just get corrupted...?
Are you using WinDbg? If so, are you using the Son of strike extension?
Bugslayer: Son-of-Strike
-or-
Drill Into .NET Framework Internals to See How the CLR Creates Runtime Objects?
We had an issue similar to this where a code bug was silent in MSVC2K5 SP1, but if you had the MSVC2K5 SP2 runtime installed it caused an error which didn't point at valid code.
Part of the problem is, when you start executing data as code you could be doing anything and so the crash location becomes useless as you cannot even get back to a valid stack trace.
We had this happen to us when the new .Net runtime install installed a newer version of the MSVC C++ Runtime in the SxS directory.
In the end our method to resolve the issue was to make the crash happen frequently and add as much logging as necessary to localize it.
could you post the stack of the faulting thread once you've grabbed and installed a copy of windbg and opened the dump file there?
we could start from there.
Your EIP was just corrupted.
Assuming the ESP is valid, you can view the callstack, just type:
dds esp [enter]
dds [enter]
You can also use the memory windows:
Set address to: esp
Set format to: Pointer&Symbol
Sometimes my c++ program crashes in debug mode, and what I got is a message box saying that an assertion failed in some of the internal memory management routines (accessing unallocated memory etc.). But I don't know where that was called from, because I didn't get any stack trace. How do I get a stack trace or at least see where it fails in my code (instead of library/ built-in routines)?
If you have a crash, you can get information about where the crash happened whether you have a debug or a release build. And you can see the call stack even if you are on a computer that does not have the source code.
To do this you need to use the PDB file that was built with your EXE. Put the PDB file inside the same directory as the EXE that crashed. Note: Even if you have the same source code, building twice and using the first EXE and the second PDB won't work. You need to use the exact PDB that was built with your EXE.
Then attach a debugger to the process that crashed. Example: windbg or VS.
Then simply checkout your call stack, while also having your threads window open. You will have to select the thread that crashed and check on the callstack for that thread. Each thread has a different call stack.
If you already have your VS debugger attached, it will automatically go to the source code that is causing the crash for you.
If the crash is happening inside a library you are using that you don't have the PDB for. There is nothing you can do.
If you run the debug version on a machine with VS, it should offer to bring it up and let you see the stack trace.
The problem is that the real problem is not on the call stack any more. If you free a pointer twice, that can result in this problem somewhere else unrelated to the program (the next time anything accesses the heap datastructures)
I wrote this blog on some tips for getting the problem to show up in the call stack so you can figure out what is going on.
http://www.atalasoft.com/cs/blogs/loufranco/archive/2007/02/06/6-_2200_Pointers_2200_-on-Debugging-Unmanaged-Code.aspx
The best tip is to use the gflags utility to make pointer issues cause immediate problems.
You can trigger a mini-dump by setting a handler for uncaught exceptions. Here's an article that explains all about minidumps
Google actually implemented their own open source crash handler called BreakPad, which also mozilla use I think (that's if you want something more serious - a rich and robust crash handler).
If I remember correctly that message box should have a button which says 'retry'. This should then break the program (in the debugger) at the point where the assertion happened.
CrashFinder can help you locate the place of the exception given the DLL and the address of the exception reported.
You can take this code and integrate it into your application to have a stack trage automatically generated when there is an uncaught exception. This is generally performed using __try{} __except{} or with a call to SetUnhandledExceptionFilter which allows you to specify a callback to all unhandled exceptions.
You can also have a post-mortem debugger installed on the client system. This is a decent, general way to get information when you do not have dump creation built into your application (maybe for an older version for which you must still get information).
Dr. Watson on Windows can be installed by running: drwtsn32 -i Running drwtsn32 (without any options) will bring up the configuration dialog. This will allow the creation of crash dump files, which you can later analyze with WinDbg or something similar.
You can use Poppy for this. You just sprinkle some macros across your code and it will gather the stack trace, together with the actual parameter values, local variables, loop counters, etc. It is very lightweight so it can be left in the release build to gather this information from crashes on end-user machines