Here I address this post for two question from your experts:
what’s the phenomenon when bcdedit /debug on and off for a user mode dll, with DebugBreak/int 3;
My really test results is:
when debug off: DebugBreak/int 3; have no effect.
when debug on: DebugBreak/int 3; will halt the system, no matter the debugger is connected or not.
I need a condition to determine if currently is in debug or not, so the code need not to modify for both debug on /off case.
Because if my resutls if right, then the code have DebugBreak will hang the system.
current a service (xxx.exe) call my user mode dll
I want to debug my dll, so I use the windbg attach to the xxx.exe, and I use the !process 0 0 xxx.exe to get the process address.
But the results is: no export is found.
Is this the correct output of windbg?
How to solve this issue?
Context:
I have debug this dll with win8/8.1 with target/host pc NET connection.
But now, I have to debug it on Win7 without serial PC.
On Fri, Dec 5, 2014 at 12:08 PM, wrote: > hi, All, > > Here I address this post for two question from your experts: > > 1. what’s the phenomenon when bcdedit /debug on and off for a user mode dll, with DebugBreak/int 3; > > My really test results is: > > when debug off: DebugBreak/int 3; have no effect. > when debug on: DebugBreak/int 3; will halt the system, no matter the debugger is connected or not. You can disable this behaviour with ‘bcdedit /dbgsettings {your dbgsettings} /noumex’.
> 2. I need a condition to determine if currently is in debug or not, so the code need not to modify for both debug on /off case. > > Because if my resutls if right, then the code have DebugBreak will hang the system. You can use IsDebuggerPresent() to check if your process has (user mode) debugger attached.
> 3. current a service (xxx.exe) call my user mode dll > I want to debug my dll, so I use the windbg attach to the xxx.exe, and I use the !process 0 0 xxx.exe to get the process address. !process is only available for kernel debugging. If you’re debugging more then one process with single instance of windbg then you can use menu “View -> Processes and threads” to display them (IIRC there is also a command to do that too).
Kris
> But the results is: no export is found. > > Is this the correct output of windbg? > How to solve this issue? > > Context: > I have debug this dll with win8/8.1 with target/host pc NET connection. > But now, I have to debug it on Win7 without serial PC. > > > > > > > > > > — > NTDEV is sponsored by OSR > > Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev > > OSR is HIRING!! See http://www.osr.com/careers > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
when code with debugbreak,
in debug on, this will cause system hang.
in deuug off, this will made the dll not loaded successfully.
Right. That’s the expected behavior. Well, the DLL will load successfully, but the process will terminate with an unhanded exception when it executes the DebugBreak, unless you have the process in a user-mode debugger.
—
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
At what condition when IsDebuggerPreset() return TRUE.
It seems that this does not related to bcdedit /debug on/off.
I have setup the connection between the target Win8 32 and Win7 32 host.
It is a NET connection.
But the IsDebuggerPreset return FALSE.
IsDebuggerPresent returns true if there is a user-mode debugger attached
to your process. It doesn’t have anything to do with a kernel debugger
connection.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
So from this results, it seems that the windbg running on the target have higher priority
than on the host ?
This is exactly what has been said on this thread. Look, you just need to think about this logically. When a debug breakpoint is encountered, that’s a CPU exception. The system starts looking for an exception handler. If a local debugger is attached, it will virtually always register itself as the handler for breakpoint exceptions, so you break into the local debugger. If not, and /debug is on, then the kernel debugger will have registered itself as the handler for user-mode breakpoint exceptions. If there is a remote windbg attached to the kernel debugger, you’ll break into it. If /debug is on, but there is no debugger, that’s an unhandled kernel exception.
If there was no debugger and /debug is off, then it is an unhandled user-mode exception, and the process is terminated.
When a user-mode program calls DebugBreak, the following possible actions will occur:
1- If a user-mode debugger is attached, the program will break into the debugger. This means that the program will pause and the debugger will become active.
2- If a user-mode debugger is not attached, but kernel-mode debugging was enabled at boot time, the entire computer will break into the kernel debugger. If a kernel debugger is not attached, the computer will freeze and await a kernel debugger.
3- If a user-mode debugger is not attached, and kernel-mode debugging is not enabled, the program will terminate with an unhandled exception, and the post-mortem (just-in-time) debugger will be activated. By default, the postmortem debugger is Dr. Watson, which will create a crash dump file and then ask you if you want to send this crash dump file to Microsoft.