I have a mini crash dump file provided by a client based on a crash in one of our applications. I open the dump file in Visual Studio 2019 and see the Process Name, Process Architecture in the Mini Dump Summary are what we'd expect for a dump from this application.
The Mini Dump Summary shows Exception Code 0xC0000409 (STATUS_STACK_BUFFER_OVERRUN).
When I chose Debug with Native Only I get "The exception thread has exited or the dump contains invalid thread information". I can't find anything about what this message means and why I am unable to debug with this dump file. I have the correct source from the same tag as the application and the symbol file from when the application was built.
After closing the message box I get "Frame no in module" screen with "The current stack frame was not found in a loaded module. Source cannot be shown for this location."
When I open the crash in Windbg I see this output:
ERROR: Unable to find system thread 199C
ERROR: The thread being debugged has either exited or cannot be accessed
ERROR: Many commands will not work properly
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
ERROR: Exception C0000409 occurred on unknown thread 199C
(2478.199c): Security check failure or stack buffer overrun - code c0000409 (first/second chance not available)
I also get the message FAILURE_BUCKET_ID: BAD_DUMP_MISSING_MEMORY_FAIL_FAST_STACK_BUFFER_OVERRUN_STACK_COOKIE_CHECK_FAILURE_MISSING_GSFRAME_c0000409_<redacted>.exe!Unknown in Windbg output.
What does "The exception thread has exited or the dump contains invalid thread information" mean and what can I do differently to debug this crash dump? Is it the nature of STATUS_STACK_BUFFER_OVERRUN that prevents a crash dump that can tell me what the offending line of code was?
Related
I'm working on a small app on Windows.
It uses CImage to write a PNG file on disk.
It just goes like this:
CImage theImage;
...
theImage.Save("D:\\xxx.png");
After the file was written on the disk and I clicked the close button on the top-right corner to exit the program. The console showed me a message like this:
Thread 0x**** has exited with code 1 (0x1)
Program "[*****] xxx.exe" has exited with code 0 (0x0).
Code 0x1 should indicate an error, right? Seems something wrong happened when the thread created by CImage::Save was writing the file.
The image file is perfectly on the disk, nothing wrong with it. And I checked the return value of Save, it also indicated success.
I have walked through all my code and I'm sure it is definitely caused by the invocation of CImage::Save, if I don't call it, this message never pops up. That is, the console would look like this:
Program "[*****] xxx.exe" has exited with code 0 (0x0).
I did some search and I found this post, but they didn't work it out either.
Even though the program didn't crash, but this message still annoys me.
Any idea? Thanks a lot.
"Code 0x1 should indicate an error, right?"
Only in the most abstract meaning of 'error'. Whoever authored the creation and destruction of the thread decided what value to return, and what that value meant. Could be that someone used some library that required cleanup which didn't get done in time, or another of 1000 possible causes. Not something to spend time on.
I got the really common Automation Error when I ran a VB6 application for the second time. However, the code worked fine under VB6 debugging mode. After I compiled the code and run some function for the second time, I would encounter the Automation Error 2147417848 - The object invoked has disconnected from its clients.
Then I debugged the application thru Visual Studio and got the following exception error:
Unhandled exception at 0x76B33E8D (oleaut32.dll) in vb6_2_12_2015.exe: 0xC0000005: Access violation reading location 0x01289B5C.
Is it because of something wrong with my dll registration?
The message means your program is accessing memory (ie a variable or object) that has been freed or never existed (usually because creation failed and the programmer didn't check). A memory address under 64K indicates a failed allocation.
To start with, compile your program without optimisations and with debugging info. When you crash do a stack trace which will list functions and parameters.
You can also start in a debugger.
windbg or ntsd (ntsd is a console program and maybe installed). Both are also from Debugging Tools For Windows.
Download and install Debugging Tools for Windows
http://msdn.microsoft.com/en-us/windows/hardware/hh852363
Install the Windows SDK but just choose the debugging tools.
Create a folder called Symbols in C:\
Start Windbg. File menu - Symbol File Path and enter
srv*C:\symbols*http://msdl.microsoft.com/download/symbols
then
windbg -o -g -G c:\windows\system32\cmd.exe /k batfile.bat
You can press F12 to stop it and kb will show the call stack (g continues the program). If there's errors it will also stop and show them.
Type lm to list loaded modules, x *!* to list the symbols and bp symbolname to set a breakpoint
da displays the ascii data found at that address
dda displaysthe value of the pointer
kv 10 displays last 10 stack frames
lm list modules
x *!* list all functions in all modules
p Step
!sysinfo machineid
If programming in VB6 then this environmental variable link=/pdb:none stores the symbols in the dll rather than seperate files. Make sure you compile the program with No Optimisations and tick the box for Create Symbolic Debug Info. Both on the Compile tab in the Project's Properties.
Also CoClassSyms (microsoft.com/msj/0399/hood/hood0399.aspx) can make symbols from type libraries.
.
I'm working on a Windows Store app and I'm getting a WinRT error that doesn't really give me any information so I would like to know how to understand these sorts of errors.
Basically I get the error on the following line which is called inside OnPointerPressed:
m_gestureRecognizer->ProcessDownEvent(args->GetCurrentPoint(nullptr));
The error is:
First-chance exception at 0x76F54B32 (KernelBase.dll) in DXAML2.exe: 0x40080201: WinRT originate error (parameters: 0x80070057, 0x00000044, 0x03CEE72C).
This error didn't used to appear, the only thing I've changed is that this line is now wrapped in an if clause which tests if the current pointer's PointerId is the same as one I've stored just using == such as:
if(args->GetCurrentPoint(nullptr)->PointerId == m_UIPointerID)
I have no idea why this has started happening.
So my question is in two parts:
More generally, how do I understand what an error such as the above means?
And does anyone know this error has suddenly started happening now that I check the pointerId?
Thanks for your time.
P.S. I guess another thing that has changed is that there will already be 2 pointers on the screen (the one that gets pushed into this GestureRecognizer) as well as another one, hence the PointerId check.
"How to Decipher such an error"...
For any WinRT originate error, you can take the third address in the parameters list (in your example, 0x03CEE72C), and find a description of your error in the memory window.
While debugging, break when your error is thrown and open the memory window via Debug -> Windows -> Memory -> Memory 1
Copy and paste the address to get your "easy-to-find" error message.
As Raman said - it's good to look up the hex values shown. The first one is the memory location which won't tell you much without the symbols/source, which in this case is reported directly by Windows. Perhaps the public symbols can shed some more light on where the error came from, but the error code lookups are more helpful.
If you Bing for 0x80070057 you will find an MSDN article on Common HRESULT Values which lists
E_INVALIDARG : One or more arguments are not valid : 0x80070057
It doesn't give you all the details of course, so you're off to theorize. Perhaps you can only call args->GetCurrentPoint(nullptr) once and you should store/reuse the value? Maybe gesture recognizer is not configured correctly? Maybe the app window is not visible at the time the exception is thrown or the thread is wrong. Maybe some expected calls to gesture recognizer were missed due to filtering those out with these "if" statements.
Good afternoon everyone.
I've got a strange issue that I just can't seem to figure out.
In the following code segment
m_technique->GetPassByIndex(0)->GetDesc(&passDesc);
result = device->CreateInputLayout(polygonLayout,numElements,passDesc.pIAInputSignature,passDesc.IAInputSignatureSize,&m_layout);
the Direct X Debug output gives the following:
First-chance exception at 0x753D37C3 (kernel32.dll) in GameTest.exe: 0xC0000005: Access violation reading location 0xCCCCCCCC.
First-chance exception at 0x75B44B32 (KernelBase.dll) in GameTest.exe: 0x0000087A (parameters: 0x00000000, 0x0083E214, 0x0083D64C).
D3D11 CORRUPTION: ID3D10Device::CreateInputLayout: Third parameter is corrupt. [ MISCELLANEOUS CORRUPTION #15: CORRUPTED_PARAMETER3]
A few things that I am unsure about. In the last line I see D3D11 CORRUPTION, but I only use D3D10 headers and libraries.
I am working in Visual Studio 2012, and I have the Windows 8 SDK installed, so that may cause problems.
I'm not sure how to proceed and any advice would be greatly appreciated.
The Map file looks like:
0002:000442e4 00000118H .idata$2 DATA
0002:000443fc 00000014H .idata$3 DATA
0002:00044410 00000b7cH .idata$4 DATA
0002:00044f8c 0000512eH .idata$6 DATA
0002:0004a0ba 00000000H .edata DATA
The Crash info looks like:
Application Error : The instruction at "0x00458ae1" referenced memory at "0x00000074". The memory could not be "read".
I'm trying to get a stack dump on the next crash, but it seems to me this is a case where we trounced the stack, then did a return, which made us end up executing data.
I'm not entirely certain though because I read some articles like this: Under the Hood Article seems to indicate this is an area of imported method names
The data that an import library provides for an imported API is kept
in several sections whose names all begin with .idata (for instance,
.idata$4, .idata$5, and .idata$6). The .idata$5 section contains a
single DWORD that, when the executable loads, contains the address of
the imported function. The .idata$6 section (if present) contains the
name of the imported function. When loading the executable into
memory, the Win32 loader uses this string to call GetProcAddress on
the imported function effectively.
Without a stack backtrace I'm kind of stuck. Am I looking at this crash the wrong way?
Forget MAP files, better use PDB files. For this enable linker option /DEBUG - yes, even for Release builds. /DEBUG is linker option, _DEBUG is compiler option. Only _DEBUG controls the code, and any conditional compilation that source/headers have put against this.
Debug builds have optimizations disabled, _DEBUG macro enabled.
Release builds have optimizations enabled, _DEBUG macro disabled.
/DEBUG would just put debugging-information into the EXE/DLL, and wont affect anything else.
Coming back to problem, when crash occurs. Do NOT close the application when WER (Windows Error Reporting) says it crashed. Instead keep it there, goto Task Manager, goto Process tab, select that crashed/crashing process, and hit "Create Dump File". Dump file (full-dump) will be created in some local folder (the path will be shown by task-manager). You can now close the crashing application (the WER window).
Now copy this .DMP file into some safe location, preferably the folder having your original Release folder. Open it in Visual Studio or WinDbg. On VS, just hit F11/F10, and you will be shown call stack. If multiple threads are running (in your crashed application), launch "Threads" view, and see the only suspended thread, double click it and you'll find the crash location.
You must have correct PDBs along with all binaries, and absolutely same code to see Code, otherwise call stack wont be good.
To get more information about PDB and stuff, you can read this article.