source code window is not displayed - WINDBG - OSR Developer Community

link管理

链接快照平台

输入网页链接，自动生成快照
标签化管理网页链接

(10e4.1f8): WOW64 breakpoint - code 4000001f (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
ntdll32!DbgBreakPoint:
00000000`7d61002d cc??? int??? 3
0:000:x86> k
ChildEBP??? RetAddr???
002dfb48 7d649b01 ntdll32!DbgBreakPoint
002dfcac 7d637010 ntdll32!LdrpInitializeProcess+0x111c
002dfd0c 7d61e99d ntdll32!_LdrpInitialize+0xd0
00000000 00000000 ntdll32!KiUserApcDispatcher+0x25

Here is the whole output.

ntdll!DbgBreakPoint:
00000000 77ef2aa0 cc????????????? int???? 3 0:000\> .effmach x86 Effective machine: x86 compatible (x86) 0:000:x86\> bp main 0:000:x86\> bl ?0 e x86 00000000 00411430??? 0001 (0001)? 0:**** TestDebug1!main
0:000:x86> g
ModLoad: 00000000 77d40000 00000000 77eb3000?? NOT_AN_IMAGE
ModLoad: 00000000 7d4c0000 00000000 7d5f0000?? NOT_AN_IMAGE
ModLoad: 00000000 7d600000 00000000 7d6f0000?? C:\WINDOWS\SysWOW64\ntdll32.dll
ModLoad: 00000000 77d40000 00000000 77eb3000?? NOT_AN_IMAGE
ModLoad: 00000000 77c20000 00000000 77d2c000?? NOT_AN_IMAGE
ModLoad: 00000000 7d4c0000 00000000 7d5f0000?? C:\WINDOWS\syswow64\kernel32.dll
ModLoad: 00000000 10200000 00000000 10323000?? C:\WINDOWS\WinSxS\x86_Microsoft.VC90.DebugCRT_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_F863C71F\MSVCR90D.dll
(10e4.1f8): WOW64 breakpoint - code 4000001f (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
ntdll32!DbgBreakPoint:
00000000 7d61002d cc????????????? int???? 3 0:000:x86\> k ChildEBP????????? RetAddr?????????? 002dfb48 7d649b01 ntdll32!DbgBreakPoint 002dfcac 7d637010 ntdll32!LdrpInitializeProcess+0x111c 002dfd0c 7d61e99d ntdll32!_LdrpInitialize+0xd0 00000000 00000000 ntdll32!KiUserApcDispatcher+0x25 0:000:x86\> g Breakpoint 0 hit TestDebug1!main: 00000000 00411430 55??? push??? ebp
0:000:x86> k
ChildEBP??? RetAddr???
002dff68 00411a38 TestDebug1!main [d:\visual studio 2008\projects\testdebug1\testdebug1\main.cpp @ 20]
002dffb8 0041187f TestDebug1!__tmainCRTStartup+0x1a8
002dffc0 7d4e7d2a TestDebug1!mainCRTStartup+0xf
002dfff0 00000000 kernel32!BaseProcessStart+0x28

#include
using namespace std;
int foo()
{
?int b = 300;
?return b;
}
int goo()
{
?int a = 400;
?return a;
}
int main()
{
?int a = 200;
?int* b = &a;
?foo();
?a = 400;
?goo();
?return 0;
}
--------------------

regards,
George

----- Original Message ----
From: Skywing
To: Kernel Debugging Interest List
Sent: Monday, October 6, 2008 4:29:40 PM
Subject: RE: [windbg] source code window is not displayed

Perhaps:

.open -a $ip

(You may also need to verify that you are in the correct machine mode, e.g.: “.effmach x86”.)

- S

-----Original Message-----
From: [email protected] [ mailto:[email protected] ] On Behalf Of Lin George
Sent: Monday, October 06, 2008 3:34 AM
To: Kernel Debugging Interest List
Subject: [windbg] source code window is not displayed

Hello everyone,

Not sure whether any of you met with the same issue. I am using x64 WinDbg, it is fine when debugging on x64 machine for an x64 binary – the source code window is displayed automatically when a break point is hit.

But with x64 WinDbg, when debugging on a x64 machine for an x86 binary, the source code window is not displayed even when a break point is hit.

My questions are,

1. Is it expected behavior?

2. How to make the source window displayed when debugging x86 binary?

thanks in advance,
George

—
You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to [email protected]

—
You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to [email protected]

Lin George wrote:

Here is my source code and related Windbg output. My questions/comments,

I find if I execute command .effmach x86 at the beginning, also with correct symbol path and source path, there is even no need to use .open -a $ip command when break point is hit in source code;

My further question is when should we execute command .effmach x86? As the 1st command to debug x86 binary under x64 machine/debugger as best practices or?

Did you read the help file before posting here? George, to repeat what
has been said many times before, you need to do more to help yourself
before flinging questions out to the public.

The answer is that it doesn’t matter. You just need to be aware that
you can change the mode if you see confusing results. If you notice
your first snipped:

ntdll32!DbgBreakPoint:
00000000`7d61002d cc int 3
0:000:x86> k

Notice the “x86” in the prompt? That tells you it’s already in x86
effective machine mode. Personally, I’ve never used .effmach, and I
doubt that it’s related to your issues.

From my output, there is only one break point, but I do not know why it breaks twice, any ideas?

It doesn’t matter. You’re talking about a very complicated situation
here: the operating system is 64-bit, and the debugger is a 64-bit
application, but you’re asking it to debug a 32-bit application, which
runs in a different processor mode under the control of a separate
subsystem. There’s an awful lot of players here. My guess (and you
could have guessed this, too) is that the breakpoint is first noticed by
the WOW64 subsystem (which is the process that controls 32-bit
processors on a 64-bit system), which reports the breakpoint to windbg.
After that breakpoint is dismissed, WinDbg is finally told that there
was a breakpoint in the 32-bit process at an address where a breakpoint
had been injected.

Tim Roberts, [email protected]
Providenza & Boekelheide, Inc.

On 10/6/08, Lin George wrote:
> Hi Skywing.
>
> 3. From my output, there is only one break point, but I do not know why it breaks twice, any ideas?
>
> More details, I donot know why breaks here,

0:000> !error 0x4000001f 1
Error code: (NTSTATUS) 0x4000001f - Exception status code used by
Win32 x86 emulation subsystem.

To expand on this, the first of these is the initial process breakpoint from the 64-bit ntdll, and the second of these is the initial process breakpoint from the 32-bit ntdll.

This is the expected behavior (wait, scratch that to avoid flames - “the way things work right now”) for launching a 32-bit executable with the 64-bit debugger.

If you use the 32-bit debugger, then you will only see one breakpoint. Likewise, if you use the 64-bit debugger to launch a 64-bit process, then you will also only see one breakpoint.

-----Original Message-----
From: [email protected] [ mailto:[email protected] ] On Behalf Of raj_r
Sent: Monday, October 06, 2008 1:58 PM
To: Kernel Debugging Interest List
Subject: Re: [windbg] source code window is not displayed

It doesn’t matter.? You’re talking about a very complicated situation
here: the operating system is 64-bit, and the debugger is a 64-bit
application, but you’re asking it to debug a 32-bit application, which
runs in a different processor mode under the control of a separate
subsystem.? There’s an awful lot of players here.? My guess (and you
could have guessed this, too) is that the breakpoint is first noticed by
the WOW64 subsystem (which is the process that controls 32-bit
processors on a 64-bit system), which reports the breakpoint to windbg.
After that breakpoint is dismissed, WinDbg is finally told that there
was a breakpoint in the 32-bit process at an address where a breakpoint
had been injected.

I agree using x86 machine to debug x86 prorgam with x86 debugger is fine. But currently I only have a x64 machine.

Anyway, your comments above means the one additonal break is expected and does not matter and I can ignore it in my “mixed” environment?

regards,
George

----- Original Message ----
From: Tim Roberts
To: Kernel Debugging Interest List
Sent: Tuesday, October 7, 2008 1:08:43 AM
Subject: Re: [windbg] source code window is not displayed

Lin George wrote:
> Here is my source code and related Windbg output. My questions/comments,
>
> 1. I find if I execute command .effmach x86 at the beginning, also with correct symbol path and source path, there is even no need to use .open -a $ip command when break point is hit in source code;
> 2. My further question is when should we execute command .effmach x86? As the 1st command to debug x86 binary under x64 machine/debugger as best practices or?
>?

Did you read the help file before posting here?? George, to repeat what
has been said many times before, you need to do more to help yourself
before flinging questions out to the public.

The answer is that it doesn’t matter.? You just need to be aware that
you can change the mode if you see confusing results.? If you notice
your first snipped:

> ntdll32!DbgBreakPoint:
> 00000000`7d61002d cc? ? ? ? ? ? ? int? ? 3
> 0:000:x86> k
>?

Notice the “x86” in the prompt?? That tells you it’s already in x86
effective machine mode.? Personally, I’ve never used .effmach, and I
doubt that it’s related to your issues.

> 3. From my output, there is only one break point, but I do not know why it breaks twice, any ideas?
>?

It doesn’t matter.? You’re talking about a very complicated situation
here: the operating system is 64-bit, and the debugger is a 64-bit
application, but you’re asking it to debug a 32-bit application, which
runs in a different processor mode under the control of a separate
subsystem.? There’s an awful lot of players here.? My guess (and you
could have guessed this, too) is that the breakpoint is first noticed by
the WOW64 subsystem (which is the process that controls 32-bit
processors on a 64-bit system), which reports the breakpoint to windbg.
After that breakpoint is dismissed, WinDbg is finally told that there
was a breakpoint in the 32-bit process at an address where a breakpoint
had been injected.

–
Tim Roberts, [email protected]
Providenza & Boekelheide, Inc.

—
You are currently subscribed to windbg as: [email protected]
To unsubscribe send a blank email to [email protected]

Thanks raj_r,

Your reply?means the one additonal break is expected and does not matter and I can ignore it in my “mixed” environment – when using x64 debugger on an x64 machine to debug x86 binary?

regards,
George

----- Original Message ----
From: raj_r
To: Kernel Debugging Interest List
Sent: Tuesday, October 7, 2008 1:58:02 AM
Subject: Re: [windbg] source code window is not displayed

On 10/6/08, Lin George wrote:
> Hi Skywing.
>
> 3. From my output, there is only one break point, but I do not know why it breaks twice, any ideas?
>
> More details, I donot know why breaks here,

0:000> !error 0x4000001f 1
Error code: (NTSTATUS) 0x4000001f - Exception status code used by
Win32 x86 emulation subsystem.

—
You are currently subscribed to windbg as: [email protected]
To unsubscribe send a blank email to [email protected]

George

----- Original Message ----
From: Skywing
To: Kernel Debugging Interest List
Sent: Tuesday, October 7, 2008 2:05:52 AM
Subject: RE: [windbg] source code window is not displayed

To expand on this, the first of these is the initial process breakpoint from the 64-bit ntdll, and the second of these is the initial process breakpoint from the 32-bit ntdll.

This is the expected behavior (wait, scratch that to avoid flames - “the way things work right now”) for launching a 32-bit executable with the 64-bit debugger.

If you use the 32-bit debugger, then you will only see one breakpoint.? Likewise, if you use the 64-bit debugger to launch a 64-bit process, then you will also only see one breakpoint.

- S

-----Original Message-----
From: [email protected] [ mailto:[email protected] ] On Behalf Of raj_r
Sent: Monday, October 06, 2008 1:58 PM
To: Kernel Debugging Interest List
Subject: Re: [windbg] source code window is not displayed

On 10/6/08, Lin George wrote:
> Hi Skywing.
>
> 3. From my output, there is only one break point, but I do not know why it breaks twice, any ideas?
>
> More details, I donot know why breaks here,

0:000> !error 0x4000001f 1
Error code: (NTSTATUS) 0x4000001f - Exception status code used by
Win32 x86 emulation subsystem.

—
You are currently subscribed to windbg as: [email protected]
To unsubscribe send a blank email to [email protected]

—
You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to [email protected]