I am trying to add a VEH handler in my code, and in it, upon first STATUS_ACCESS_VIOLATION, I set the Trace bit to 1 by setting the exc->ContextRecord->EFlags |= 0x100 so as to single step the violation. I see that the handler is getting called for ACCESS_VIOLATION but never getting called with exc->ExceptionRecord->ExceptionCode == STATUS_SINGLE_STEP after stepping over the offending code.
I am suspecting that the debugger is removing the 0x100 from the EFlags when it runs its handler. If I run in a command prompt, I see that it is getting hit. Is there anyway I can make the debugger not alter the trace flag and allow my handler to get called with ExceptionCode = STATUS_SINGLE_STEP?
thanks
Related
I am picking up someone else's C++ code in MS Visual Studio and have encountered the line:
if (l > n) _asm{int 3};
I understand that is is meant to break to the debugger. I also understand that it's deprecated and has been replaced with:
__debugbreak()
My question is... how does this work? Why should such an inline assembler command result in the debugger?
It is the same thing as setting a breakpoint with the IDE, but the difference is that with the IDE or any other debugger, it sets a breakpoint overwriting the chosen opcode with int 3 and with __asm { int 3 }, it sets as a new opcode line.
To add to the comment, int 3 is an assembly instruction that triggers a hardware interrupt, which causes the running thread ( your code ) to halt while the operating system services that interrupt. Not sure of the specifics, but the debugger must be able to hook into the os to get a notification of that interrupt, and act appropriately.
Read more: https://blogs.msdn.microsoft.com/kangsu/2005/09/07/no-more-int-3/
Using Qt 5.1.1 for Windows 32-bit (with MinGW 4.8), when debugging GDB wants to drop into dissassembly while debugging code after the first time.
I make a "Plain C++" project, insert some simple code:
int x = 5;
cout << x << endl;
return 0;
Build, and debug it with a breakpoint on first line. First time through it debugs just fine stepping through the code with "Step Over". Any debug session after that, it will drop into dissamebly view of ntdll when it hits cout (or anything else library related).
Operate By Instruction is not checked and there is debug information for my code. It works as expected once, then refuses to.
I can delete the build folder and the .pro.user file and the project still exhibits the same behavior after a new build. Even tried wiping my QTProject settings folder. There seems to be no way to debug just my code more than once without it wanting to drop into assembly instead of stepping over statements. If I make a new project, I can debug it normally once, then it starts behaving the same way.
Looking for a fix or suggestions of things to try.
Had a chance to go back...diffed the debugger log on the good initial vs sequential runs. Everything looks similar until I get to this in good run:
=thread-exited,id="2",group-id="i1"
sThread 2 in group i1 exited
~"[Switching to Thread 5588.0x239c]\n"
=thread-selected,id="1"
sThread 1 selected
Bad runs never have that. Later, this is unique to bad run:
>1272^done,threads=[{id="2",target-id="Thread 7148.0x242c",frame=
{level="0",addr="0x7792fd91",func="ntdll!RtlFindSetBits",args=
[],from="C:\\Windows\\system32\\ntdll.dll"},state="stopped"},
//LINES BELOW COMMON TO GOOD+BAD
{id="1",target-id="Thread 7148.0x1bbc",frame=
{level="0",addr="0x00401606",func="main",args=
[],file="..\\untitled8\\main.cpp",fullname=
"C:\\Users\\Andrew\\Desktop\\untitled8\\main.cpp",line="7"},
state="stopped"}],current-thread-id="1"*
Then once it hits the breakpoint, good run shows this:
*stopped,reason="end-stepping-range",frame={addr="0x00401620",func="fu0__ZSt4cout",args[],
file="..\untitled8\main.cpp",
fullname="C:\Users\Andrew\Desktop\untitled8\main.cpp",line="9"},
thread-id="1",stopped-threads="all"
Bad run shows this:
>*stopped,reason="signal-received",signal-name="SIGTRAP",signal-meaning="Trace/breakpoint trap",
frame={addr="0x7792000d",func="ntdll!LdrFindResource_U",args=[],
from="C:\\Windows\\system32\\ntdll.dll"},thread-id="2",stopped-threads="all"
dNOTE: INFERIOR SPONTANEOUS STOP sStopped.
dState changed from InferiorRunOk(11) to InferiorStopOk(14) [master]
dSIGTRAP CONSIDERED HARMLESS. CONTINUING.
sStopped: "signal-received"
>=thread-selected,id="2"
sThread 2 selected
<1283-thread-info
>1283^done,threads=[{id="2",target-id="Thread 7148.0x242c",frame=
{level="0",addr="0x7792000d",func="ntdll!LdrFindResource_U",args=[],
from="C:\\Windows\\system32\\ntdll.dll"},state="stopped"},
{id="1",target-id="Thread 7148.0x1bbc",
frame={level="0",addr="0x756a133d",func="KERNEL32!GetPrivateProfileStructA",
args=[],from="C:\\Windows\\syswow64\\kernel32.dll"},state="stopped"}],current-thread-id="2"
<1284-stack-list-frames 0 20
>1284^done,stack=[frame={level="0",addr="0x7792000d",func="ntdll!LdrFindResource_U",
from="C:\\Windows\\system32\\ntdll.dll"},
frame={level="1",addr="0x779af926",
func="ntdll!RtlQueryTimeZoneInformation",
from="C:\\Windows\\system32\\ntdll.dll"},frame={level="2",addr="0x75f45dd1",func="??"},
frame={level="3",addr="0x00000000",func="??"}]
<1285-stack-select-frame 0
<1286disassemble 0x7791fff9,0x77920071
<1287bb options:fancy,autoderef,dyntype vars: expanded:return,local,watch,inspect typeformats: formats: watchers:
>1285^done
>&"disassemble 0x7791fff9,0x77920071\n"
>~"Dump of assembler code from 0x7791fff9 to 0x77920071:\n"
>~" 0x7791fff9 <ntdll!LdrFindResource_U+60953>:\t"
>&"Cannot access memory at address 0x7791fff9\n"
>1286^error,msg="Cannot access memory at address 0x7791fff9"
sDisassembler failed: Cannot access memory at address 0x7791fff9
Looks like for some reason that extra thread is not exiting when expected and qtcreator/gdb convince themselves there are breakpoints in ntdll that I want to stop at.
I have a Visual C++ 9 Win32 application that uses a third-party library. When a function from that library is called with a certain set of parameters the program crashes with "exception code 0xC000000D".
I tried to attach Visual Studio debugger - no exceptions are thrown (neither C++ nor structured like access violations) and terminate() is not called either. Still the program just ends silently.
How does it happen that the program just ends abnormally but without stopping in the debugger? How can I localize the problem?
That's STATUS_INVALID_PARAMETER, use WinDbg to track down who threw it (i.e. attach WinDbg, sxe eh then g.
Other answers and comments to the question helped a lot. Here's what I did.
I notices that if I run the program under Visual Studio debugger it just ends silently, but if I run it without debugger it crashes with a message box (usual Windows message box saying that I lost my unsaved data and everyone is sooo sorry).
So I started the program wihtout debugger, let it crash and then - while the message box was still there - attached the debugger and hit "Break". Here's the call stack:
ntdll.dll!_KiFastSystemCallRet#0()
ntdll.dll!_ZwWaitForMultipleObjects#20() + 0xc bytes
kernel32.dll!_WaitForMultipleObjectsEx#20() - 0x48 bytes
kernel32.dll!_WaitForMultipleObjects#16() + 0x18 bytes
faultrep.dll!StartDWException() + 0x5df bytes
faultrep.dll!ReportFault() + 0x533 bytes
kernel32.dll!_UnhandledExceptionFilter#4() + 0x55c bytes
//SomeThirdPartyLibraryFunctionAddress
//SomeThirdPartyLibraryFunctionAddress
//SomeThirdPartyLibraryFunctionAddress
//SomeThirdPartyLibraryFunctionAddress
//OurCodeInvokingThirdPartyLibraryCode
so obviously that's some problem inside the trird-party library. According to MSDN, UnhandledExceptionFilter() is called in fatal situations and clearly the call is done because of some problem in the library code. So we'll try to work the problem out with the library vendor first.
If you don't have source and debugging information for your 3rd party library, you will not be able to step into it with the debugger. As I see it, your choices are;
Put together a simple test case illustrating the crash and send it onto the library developer
Wrap that library function in your own code that checks for illegal parameters and throw an exception / return an error code when they are passed by your own application
Rewrite the parts of the library that do not work or use an alternative
Very difficult to fix code that is provided as object only
Edit You might also be able to exit more gracefully using __try __finally around your main message loop, something like
int CMyApp::Run()
{
__try
{
int i = CWinApp::Run();
m_Exitok = MAGIC_EXIT_NO;
return i;
}
__finally
{
if (m_Exitok != MAGIC_EXIT_NO)
FaultHandler();
}
}
I am now trying to use this Application Verifier debugging tool, but i am stuck, first of all: it breaks the program at a line that is simple variable set line (s = 1; for example)
Secondly, now when i run this program under debugger, my program seems to have changed its behaviour: i am drawing image, and now one of the colors has changed o_O, all those parts of the image that i dont draw on, has changed the color to #CDCDCD when it should be #000000, and i already set the default color to zero, still it becomes to #CDCDCD.
How do i make any sense to this?
Here is the output AV gave me:
VERIFIER STOP 00000002: pid 0x8C0: Access violation exception.
14873000 : Invalid address causing the exception
004E422C : Code address executing the invalid access
0012EB08 : Exception record
0012EB24 : Context record
AVRF: Noncontinuable verifier stop 00000002 encountered. Terminating process ...
The program '[2240] test.exe: Native' has exited with code -1073741823 (0xc0000001).
Typically when breakpoints are hit like this (via AV or an unhandled exception, etc.) inside a debugger, there is a green arrow pointing to a line of code. That arrow is pointing to the next statement to execute when the thread returns from the current function. Perhaps this green arrow is pointing to the line where you wrote "s = 1", but really the offending code is the line above it. Now I can't see your code so I can't exactly know for sure and I don't have enough rep to post a comment - but this is something that is easy to check the next time the breakpoint is hit.
I am willing to bet that s is NOT a "simple" variable. I'm much more likely to believe it's something like this:
class Foo;
int s;
void Bar() {
s = 1;
}
};
Sure, it looks like a simple s=1 statement, but in reality it is a this->s=1 statement. And if this is an invalid pointer, this->s isn't a proper variable either.
I am using OpenCV 1 to do some image processing, and am confused about the cvSetErrMode function (which is part of CxCore).
OpenCV has three error modes.
Leaf: The program is terminated after the error handler is called.
Parent: The program is not terminated, but the error handler is called.
Silent: Similar to Parent mode, but no error handler is called
At the start of my code, I call cvSetErrMode(CV_ErrModeParent) to switch from the default 'leaf' mode to 'parent' mode so my application is not terminated with an exception/assertion pop up.
Unfortunately 'parent' mode doesn't seem to be working. I still get the message dialog pop up, and my application still terminates.
If I call cvSetErrMode(CV_ErrModeSilent) then it actually goes silent, and no longer quits the application or throws up a dialog... but this also means that I dont know that an error has occurred. In this case, I think the mode is being set correctly.
Has anyone else seem this behaviour before and might be able to recommend a solution?
References:
cvSetErrMode function reference
Open CV Error handling mode reference
I am going to answer my own question, because after some fiddling around I have worked out what happens.
When you switch to 'parent' mode instead of leaf mode, there is an error handler that gets called cvGuiBoxReport(). cvGuiBoxReport() is the default error handler. It seems that even in parent mode, cvGuiBoxReport() still terminates your application! Oops.
So, to get around that you can write your own error handler, and redirect the error to be handled and NOT terminate the application.
An example error handler:
int MyErrorHandler(int status, const char* func_name, const char* err_msg, const char* file_name, int line, void*)
{
std::cerr << "Woohoo, my own custom error handler" << std::endl;
return 0;
}
You can set up parent mode and redirect your error with:
cvSetErrMode(CV_ErrModeParent);
cvRedirectError(MyErrorHandler);
In a week of servers crashing from uploading corrupt or empty images to our image processing server, here are some thoughts on how I solved the intricacies of OpenCV's error handling. We are using V2.2 in a C++ server.
The problem arises in cv::imread() and cv::imdecode() when the image to be loaded is corrupt (or empty). Normally OpenCV just exits the process with with some error messages, not a good idea when you're running a server which should work all the time.
Reviewing the source code at https://code.ros.org/trac/opencv/browser/trunk/opencv/modules/core/include/opencv2/core/core.hpp I ignored the hint in the source comments for cv::setBreakOnError() and discovered the that following pattern works:
cv::setBreakOnError(true); // Can be set globally
...
...
cv::Mat srcImage = cv::imread(filename, 1);
if (!srcImage.data) throw std::exception("bad image");
cv::imread() will now not exit the process, but passes control to your own exception handling, so you can do with it what you like.
Finding this has saved a lot of heartbreak.