Using WinDbg on application-level code

OSR_Community_User · September 8, 2010, 6:11pm

As a piece of curiosity, and to allow me to demonstrate something, I was
investigating the use of WinDbg in debugging user-level applications. I
created a truly-trivial hello-world equivalent, started WinDbg, did an “Open
Executable”, and ran it. Sure enough, it popped up a console window and the
output came out.

So I tried to set a breakpoint. It didn’t work. Odd. So I started
single-stepping, and found myself in code I didn’t recognize as belonging to
my program. Odd. In fact, I found myself in NTDLL.DLL, without symbols.
Odder. So I set up a pointer to the msdl symbols server. Still no luck; it
appears either the symbol server doesn’t support ntdll.dll in user mode or I
did something else wrong (but I copied-and-pasted the line from a version of
WinDbg I use for analyzing crash dumps, where it does work, at least for the
kernel). .reload did nothing. Ultimately, it looked like it was executing
code that would *cause* my program to run, rather than executing my
program’s code. Odder still.

Did I miss something essential about using WinDbg for applications? (This
is entirely possible, as I normally only use it for driver work, where I
have only the usual and familiar problems with it).
joe

mm1 · September 8, 2010, 6:14pm

No idea, but turning on noisy symbol loading would seem like a reasonable
place to start.

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Joseph M. Newcomer
Sent: Wednesday, September 08, 2010 6:11 PM
To: Kernel Debugging Interest List
Subject: [windbg] Using WinDbg on application-level code

As a piece of curiosity, and to allow me to demonstrate something, I was
investigating the use of WinDbg in debugging user-level applications. I
created a truly-trivial hello-world equivalent, started WinDbg, did an “Open
Executable”, and ran it. Sure enough, it popped up a console window and the
output came out.

So I tried to set a breakpoint. It didn’t work. Odd. So I started
single-stepping, and found myself in code I didn’t recognize as belonging to
my program. Odd. In fact, I found myself in NTDLL.DLL, without symbols.
Odder. So I set up a pointer to the msdl symbols server. Still no luck; it
appears either the symbol server doesn’t support ntdll.dll in user mode or I
did something else wrong (but I copied-and-pasted the line from a version of
WinDbg I use for analyzing crash dumps, where it does work, at least for the
kernel). .reload did nothing. Ultimately, it looked like it was executing
code that would *cause* my program to run, rather than executing my
program’s code. Odder still.

Did I miss something essential about using WinDbg for applications? (This
is entirely possible, as I normally only use it for driver work, where I
have only the usual and familiar problems with it).
joe

WINDBG is sponsored by OSR

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

Jen-Lung_Chiu · September 8, 2010, 6:26pm

Questions:

How do you set up the breakpoint?
Yes, please turn on symbols spew to get more information on symbols loading. After setup the .sympath (or just run .symfix), “!sym noisy” then “.reload /f” would do.

Please check http://msdn.microsoft.com/en-us/library/ff550949(v=VS.85).aspx for more information on the initial breakpoint.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Joseph M. Newcomer
Sent: Wednesday, September 08, 2010 03:11 PM
To: Kernel Debugging Interest List
Subject: [windbg] Using WinDbg on application-level code

As a piece of curiosity, and to allow me to demonstrate something, I was investigating the use of WinDbg in debugging user-level applications. I created a truly-trivial hello-world equivalent, started WinDbg, did an “Open Executable”, and ran it. Sure enough, it popped up a console window and the output came out.

So I tried to set a breakpoint. It didn’t work. Odd. So I started single-stepping, and found myself in code I didn’t recognize as belonging to my program. Odd. In fact, I found myself in NTDLL.DLL, without symbols.
Odder. So I set up a pointer to the msdl symbols server. Still no luck; it appears either the symbol server doesn’t support ntdll.dll in user mode or I did something else wrong (but I copied-and-pasted the line from a version of WinDbg I use for analyzing crash dumps, where it does work, at least for the kernel). .reload did nothing. Ultimately, it looked like it was executing code that would *cause* my program to run, rather than executing my program’s code. Odder still.

Did I miss something essential about using WinDbg for applications? (This is entirely possible, as I normally only use it for driver work, where I have only the usual and familiar problems with it).
joe

WINDBG is sponsored by OSR

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

Don_Burn_1 · September 8, 2010, 6:26pm

Joe,

I you are using the kernel mode Windbg setup to debug a user mode
program, you either need a hardcoded breakpoint in the program, or there
is a magic command in Windbg which I can never remember. Personally, I
just code the breakpoint.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“Joseph M. Newcomer” wrote in message
news:xxxxx@windbg:

> As a piece of curiosity, and to allow me to demonstrate something, I was
> investigating the use of WinDbg in debugging user-level applications. I
> created a truly-trivial hello-world equivalent, started WinDbg, did an “Open
> Executable”, and ran it. Sure enough, it popped up a console window and the
> output came out.
>
> So I tried to set a breakpoint. It didn’t work. Odd. So I started
> single-stepping, and found myself in code I didn’t recognize as belonging to
> my program. Odd. In fact, I found myself in NTDLL.DLL, without symbols.
> Odder. So I set up a pointer to the msdl symbols server. Still no luck; it
> appears either the symbol server doesn’t support ntdll.dll in user mode or I
> did something else wrong (but I copied-and-pasted the line from a version of
> WinDbg I use for analyzing crash dumps, where it does work, at least for the
> kernel). .reload did nothing. Ultimately, it looked like it was executing
> code that would cause my program to run, rather than executing my
> program’s code. Odder still.
>
> Did I miss something essential about using WinDbg for applications? (This
> is entirely possible, as I normally only use it for driver work, where I
> have only the usual and familiar problems with it).
> joe

OSR_Community_User · September 8, 2010, 6:32pm

I have used the Microsoft symbol server with user mode debugging. I have set
breakpoints in some of the services. I did this by attaching to a process so
it is not exactly the same.

Bill Wandel

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Joseph M. Newcomer
Sent: Wednesday, September 08, 2010 6:11 PM
To: Kernel Debugging Interest List
Subject: [windbg] Using WinDbg on application-level code

As a piece of curiosity, and to allow me to demonstrate something, I was
investigating the use of WinDbg in debugging user-level applications. I
created a truly-trivial hello-world equivalent, started WinDbg, did an “Open
Executable”, and ran it. Sure enough, it popped up a console window and the
output came out.

So I tried to set a breakpoint. It didn’t work. Odd. So I started
single-stepping, and found myself in code I didn’t recognize as belonging to
my program. Odd. In fact, I found myself in NTDLL.DLL, without symbols.
Odder. So I set up a pointer to the msdl symbols server. Still no luck; it
appears either the symbol server doesn’t support ntdll.dll in user mode or I
did something else wrong (but I copied-and-pasted the line from a version of
WinDbg I use for analyzing crash dumps, where it does work, at least for the
kernel). .reload did nothing. Ultimately, it looked like it was executing
code that would *cause* my program to run, rather than executing my
program’s code. Odder still.

Did I miss something essential about using WinDbg for applications? (This
is entirely possible, as I normally only use it for driver work, where I
have only the usual and familiar problems with it).
joe

WINDBG is sponsored by OSR

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

mm1 · September 8, 2010, 6:35pm

Isn’t the initial breakpoint normally in ntdll?

On Sep 8, 2010 6:32 PM, “Bill Wandel” wrote:
> I have used the Microsoft symbol server with user mode debugging. I have
set
> breakpoints in some of the services. I did this by attaching to a process
so
> it is not exactly the same.
>
> Bill Wandel
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Joseph M. Newcomer
> Sent: Wednesday, September 08, 2010 6:11 PM
> To: Kernel Debugging Interest List
> Subject: [windbg] Using WinDbg on application-level code
>
> As a piece of curiosity, and to allow me to demonstrate something, I was
> investigating the use of WinDbg in debugging user-level applications. I
> created a truly-trivial hello-world equivalent, started WinDbg, did an
“Open
> Executable”, and ran it. Sure enough, it popped up a console window and
the
> output came out.
>
> So I tried to set a breakpoint. It didn’t work. Odd. So I started
> single-stepping, and found myself in code I didn’t recognize as belonging
to
> my program. Odd. In fact, I found myself in NTDLL.DLL, without symbols.
> Odder. So I set up a pointer to the msdl symbols server. Still no luck; it
> appears either the symbol server doesn’t support ntdll.dll in user mode or
I
> did something else wrong (but I copied-and-pasted the line from a version
of
> WinDbg I use for analyzing crash dumps, where it does work, at least for
the
> kernel). .reload did nothing. Ultimately, it looked like it was executing
> code that would cause my program to run, rather than executing my
> program’s code. Odder still.
>
> Did I miss something essential about using WinDbg for applications? (This
> is entirely possible, as I normally only use it for driver work, where I
> have only the usual and familiar problems with it).
> joe
>
>
> —
> WINDBG is sponsored by OSR
>
> 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
>
>
> —
> WINDBG is sponsored by OSR
>
> 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

Jen-Lung_Chiu · September 8, 2010, 6:36pm

Don’t think you need to code the breakpoint. WINDBG is quite capable as user-mode debugger. Below is debugger spew when debug the “Hello World” app, it sets a breakpoint at the start of wmain(), hits the breakpoints, then continues execution.

CommandLine: \dbg\test\Simple\objfre\i386\simple.exe
Symbol search path is: srv*http://msdl.microsoft.com/download/symbols
Executable search path is:
ModLoad: 00d00000 00d05000 simple.exe
ModLoad: 76fc0000 77140000 ntdll.dll
ModLoad: 76810000 76910000 E:\Windows\syswow64\kernel32.dll
ModLoad: 763f0000 76436000 E:\Windows\syswow64\KERNELBASE.dll
ModLoad: 754a0000 7554c000 E:\Windows\syswow64\msvcrt.dll
(82c.1358): Break instruction exception - code 80000003 (first chance)
eax=00000000 ebx=00000000 ecx=9ea30000 edx=0020df38 esi=fffffffe edi=76fe3b90
eip=77060b2d esp=000cf3a4 ebp=000cf3d0 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
ntdll!LdrpDoDebuggerBreak+0x2c:
77060b2d cc int 3

0:000> .reload /f
Reloading current modules
…

0:000> k
ChildEBP RetAddr
000cf3d0 770412e9 ntdll!LdrpDoDebuggerBreak+0x2c
000cf548 7701209f ntdll!LdrpInitializeProcess+0x132f
000cf598 76ff9d99 ntdll!_LdrpInitialize+0x78
000cf5a8 00000000 ntdll!LdrInitializeThunk+0x10

0:000> x simple!wmain*
006311f0 simple!wmain (int, unsigned short **)
006314a0 simple!wmainCRTStartup (void)

0:000> bp simple!wmain

0:000> g
Breakpoint 0 hit
eax=000d0000 ebx=00000000 ecx=00d03674 edx=00000000 esi=00000001 edi=00000000
eip=00d011f0 esp=000cf7e4 ebp=000cf820 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
simple!wmain:
00d011f0 8bff mov edi,edi

0:000> k
ChildEBP RetAddr
000cf7e0 00d01433 simple!wmain
000cf820 76823677 simple!__wmainCRTStartup+0x100
000cf82c 76ff9e12 kernel32!BaseThreadInitThunk+0xe
000cf86c 76ff9de5 ntdll!__RtlUserThreadStart+0x70
000cf884 00000000 ntdll!_RtlUserThreadStart+0x1b

0:000> g
Hello world
eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=770c2100 edi=770c20c0
eip=76fdfc52 esp=000cf760 ebp=000cf77c iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
ntdll!ZwTerminateProcess+0x12:
76fdfc52 83c404 add esp,4

0:000> k
ChildEBP RetAddr
000cf760 7701a2d4 ntdll!ZwTerminateProcess+0x12
000cf77c 76827362 ntdll!RtlExitUserProcess+0x85
000cf790 754b36dc kernel32!ExitProcessStub+0x12
000cf79c 754b3371 msvcrt!__crtExitProcess+0x17
000cf7d4 754b36bb msvcrt!doexit+0xac
000cf7e8 00d0144a msvcrt!exit+0x11
000cf820 76823677 simple!__wmainCRTStartup+0x117
000cf82c 76ff9e12 kernel32!BaseThreadInitThunk+0xe
000cf86c 76ff9de5 ntdll!__RtlUserThreadStart+0x70
000cf884 00000000 ntdll!_RtlUserThreadStart+0x1b

0:000> q
quit:

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Wednesday, September 08, 2010 03:26 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Using WinDbg on application-level code

Joe,

I you are using the kernel mode Windbg setup to debug a user mode program, you either need a hardcoded breakpoint in the program, or there is a magic command in Windbg which I can never remember. Personally, I just code the breakpoint.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“Joseph M. Newcomer” wrote in message
news:xxxxx@windbg:

> As a piece of curiosity, and to allow me to demonstrate something, I
> was investigating the use of WinDbg in debugging user-level
> applications. I created a truly-trivial hello-world equivalent,
> started WinDbg, did an “Open Executable”, and ran it. Sure enough, it
> popped up a console window and the output came out.
>
> So I tried to set a breakpoint. It didn’t work. Odd. So I started
> single-stepping, and found myself in code I didn’t recognize as
> belonging to my program. Odd. In fact, I found myself in NTDLL.DLL, without symbols.
> Odder. So I set up a pointer to the msdl symbols server. Still no
> luck; it appears either the symbol server doesn’t support ntdll.dll in
> user mode or I did something else wrong (but I copied-and-pasted the
> line from a version of WinDbg I use for analyzing crash dumps, where
> it does work, at least for the kernel). .reload did nothing.
> Ultimately, it looked like it was executing code that would cause my
> program to run, rather than executing my program’s code. Odder still.
>
> Did I miss something essential about using WinDbg for applications?
> (This is entirely possible, as I normally only use it for driver work,
> where I have only the usual and familiar problems with it).
> joe

—
WINDBG is sponsored by OSR

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

Don_Burn_1 · September 8, 2010, 7:07pm

And the output below is for using Windbg as a user space debugger. If
you have it setup for kernel mode debugging this does not work.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“Jen-Lung Chiu” wrote in message
news:xxxxx@windbg:

> Don’t think you need to code the breakpoint. WINDBG is quite capable as user-mode debugger. Below is debugger spew when debug the “Hello World” app, it sets a breakpoint at the start of wmain(), hits the breakpoints, then continues execution.
>
> Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
> Copyright (c) Microsoft Corporation. All rights reserved.
>
> CommandLine: \dbg\test\Simple\objfre\i386\simple.exe
> Symbol search path is: srvhttp://msdl.microsoft.com/download/symbols
> Executable search path is:
> ModLoad: 00d00000 00d05000 simple.exe
> ModLoad: 76fc0000 77140000 ntdll.dll
> ModLoad: 76810000 76910000 E:\Windows\syswow64\kernel32.dll
> ModLoad: 763f0000 76436000 E:\Windows\syswow64\KERNELBASE.dll
> ModLoad: 754a0000 7554c000 E:\Windows\syswow64\msvcrt.dll
> (82c.1358): Break instruction exception - code 80000003 (first chance)
> eax=00000000 ebx=00000000 ecx=9ea30000 edx=0020df38 esi=fffffffe edi=76fe3b90
> eip=77060b2d esp=000cf3a4 ebp=000cf3d0 iopl=0 nv up ei pl zr na pe nc
> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
> ntdll!LdrpDoDebuggerBreak+0x2c:
> 77060b2d cc int 3
>
> 0:000> .reload /f
> Reloading current modules
> …
>
> 0:000> k
> ChildEBP RetAddr
> 000cf3d0 770412e9 ntdll!LdrpDoDebuggerBreak+0x2c
> 000cf548 7701209f ntdll!LdrpInitializeProcess+0x132f
> 000cf598 76ff9d99 ntdll!_LdrpInitialize+0x78
> 000cf5a8 00000000 ntdll!LdrInitializeThunk+0x10
>
> 0:000> x simple!wmain
> 006311f0 simple!wmain (int, unsigned short **)
> 006314a0 simple!wmainCRTStartup (void)
>
> 0:000> bp simple!wmain
>
> 0:000> g
> Breakpoint 0 hit
> eax=000d0000 ebx=00000000 ecx=00d03674 edx=00000000 esi=00000001 edi=00000000
> eip=00d011f0 esp=000cf7e4 ebp=000cf820 iopl=0 nv up ei pl zr na pe nc
> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
> simple!wmain:
> 00d011f0 8bff mov edi,edi
>
> 0:000> k
> ChildEBP RetAddr
> 000cf7e0 00d01433 simple!wmain
> 000cf820 76823677 simple! wmainCRTStartup+0x100
> 000cf82c 76ff9e12 kernel32!BaseThreadInitThunk+0xe
> 000cf86c 76ff9de5 ntdll! RtlUserThreadStart+0x70
> 000cf884 00000000 ntdll!_RtlUserThreadStart+0x1b
>
> 0:000> g
> Hello world
> eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=770c2100 edi=770c20c0
> eip=76fdfc52 esp=000cf760 ebp=000cf77c iopl=0 nv up ei pl nz na po nc
> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
> ntdll!ZwTerminateProcess+0x12:
> 76fdfc52 83c404 add esp,4
>
> 0:000> k
> ChildEBP RetAddr
> 000cf760 7701a2d4 ntdll!ZwTerminateProcess+0x12
> 000cf77c 76827362 ntdll!RtlExitUserProcess+0x85
> 000cf790 754b36dc kernel32!ExitProcessStub+0x12
> 000cf79c 754b3371 msvcrt! crtExitProcess+0x17
> 000cf7d4 754b36bb msvcrt!doexit+0xac
> 000cf7e8 00d0144a msvcrt!exit+0x11
> 000cf820 76823677 simple! wmainCRTStartup+0x117
> 000cf82c 76ff9e12 kernel32!BaseThreadInitThunk+0xe
> 000cf86c 76ff9de5 ntdll!__RtlUserThreadStart+0x70
> 000cf884 00000000 ntdll!_RtlUserThreadStart+0x1b
>
> 0:000> q
> quit:
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
> Sent: Wednesday, September 08, 2010 03:26 PM
> To: Kernel Debugging Interest List
> Subject: Re:[windbg] Using WinDbg on application-level code
>
> Joe,
>
> I you are using the kernel mode Windbg setup to debug a user mode program, you either need a hardcoded breakpoint in the program, or there is a magic command in Windbg which I can never remember. Personally, I just code the breakpoint.
>
>
> Don Burn (MVP, Windows DKD)
> Windows Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
>
>
>
>
> “Joseph M. Newcomer” wrote in message
> news:xxxxx@windbg:
>
> > As a piece of curiosity, and to allow me to demonstrate something, I
> > was investigating the use of WinDbg in debugging user-level
> > applications. I created a truly-trivial hello-world equivalent,
> > started WinDbg, did an “Open Executable”, and ran it. Sure enough, it
> > popped up a console window and the output came out.
> >
> > So I tried to set a breakpoint. It didn’t work. Odd. So I started
> > single-stepping, and found myself in code I didn’t recognize as
> > belonging to my program. Odd. In fact, I found myself in NTDLL.DLL, without symbols.
> > Odder. So I set up a pointer to the msdl symbols server. Still no
> > luck; it appears either the symbol server doesn’t support ntdll.dll in
> > user mode or I did something else wrong (but I copied-and-pasted the
> > line from a version of WinDbg I use for analyzing crash dumps, where
> > it does work, at least for the kernel). .reload did nothing.
> > Ultimately, it looked like it was executing code that would cause my
> > program to run, rather than executing my program’s code. Odder still.
> >
> > Did I miss something essential about using WinDbg for applications?
> > (This is entirely possible, as I normally only use it for driver work,
> > where I have only the usual and familiar problems with it).
> > joe
>
>
> —
> WINDBG is sponsored by OSR
>
> 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

mm1 · September 8, 2010, 7:10pm

He didn’t - he opened an executive.

On Sep 8, 2010 7:07 PM, “Don Burn” wrote:
> And the output below is for using Windbg as a user space debugger. If
> you have it setup for kernel mode debugging this does not work.
>
>
> Don Burn (MVP, Windows DKD)
> Windows Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
>
>
>
>
> “Jen-Lung Chiu” wrote in message
> news:xxxxx@windbg:
>
>> Don’t think you need to code the breakpoint. WINDBG is quite capable as
user-mode debugger. Below is debugger spew when debug the “Hello World” app,
it sets a breakpoint at the start of wmain(), hits the breakpoints, then
continues execution.
>>
>> Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
>> Copyright (c) Microsoft Corporation. All rights reserved.
>>
>> CommandLine: \dbg\test\Simple\objfre\i386\simple.exe
>> Symbol search path is: srvhttp://msdl.microsoft.com/download/symbols
>> Executable search path is:
>> ModLoad: 00d00000 00d05000 simple.exe
>> ModLoad: 76fc0000 77140000 ntdll.dll
>> ModLoad: 76810000 76910000 E:\Windows\syswow64\kernel32.dll
>> ModLoad: 763f0000 76436000 E:\Windows\syswow64\KERNELBASE.dll
>> ModLoad: 754a0000 7554c000 E:\Windows\syswow64\msvcrt.dll
>> (82c.1358): Break instruction exception - code 80000003 (first chance)
>> eax=00000000 ebx=00000000 ecx=9ea30000 edx=0020df38 esi=fffffffe
edi=76fe3b90
>> eip=77060b2d esp=000cf3a4 ebp=000cf3d0 iopl=0 nv up ei pl zr na pe nc
>> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
>> ntdll!LdrpDoDebuggerBreak+0x2c:
>> 77060b2d cc int 3
>>
>> 0:000> .reload /f
>> Reloading current modules
>> …
>>
>> 0:000> k
>> ChildEBP RetAddr
>> 000cf3d0 770412e9 ntdll!LdrpDoDebuggerBreak+0x2c
>> 000cf548 7701209f ntdll!LdrpInitializeProcess+0x132f
>> 000cf598 76ff9d99 ntdll!_LdrpInitialize+0x78
>> 000cf5a8 00000000 ntdll!LdrInitializeThunk+0x10
>>
>> 0:000> x simple!wmain
>> 006311f0 simple!wmain (int, unsigned short **)
>> 006314a0 simple!wmainCRTStartup (void)
>>
>> 0:000> bp simple!wmain
>>
>> 0:000> g
>> Breakpoint 0 hit
>> eax=000d0000 ebx=00000000 ecx=00d03674 edx=00000000 esi=00000001
edi=00000000
>> eip=00d011f0 esp=000cf7e4 ebp=000cf820 iopl=0 nv up ei pl zr na pe nc
>> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
>> simple!wmain:
>> 00d011f0 8bff mov edi,edi
>>
>> 0:000> k
>> ChildEBP RetAddr
>> 000cf7e0 00d01433 simple!wmain
>> 000cf820 76823677 simple! wmainCRTStartup+0x100
>> 000cf82c 76ff9e12 kernel32!BaseThreadInitThunk+0xe
>> 000cf86c 76ff9de5 ntdll! RtlUserThreadStart+0x70
>> 000cf884 00000000 ntdll!_RtlUserThreadStart+0x1b
>>
>> 0:000> g
>> Hello world
>> eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=770c2100
edi=770c20c0
>> eip=76fdfc52 esp=000cf760 ebp=000cf77c iopl=0 nv up ei pl nz na po nc
>> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
>> ntdll!ZwTerminateProcess+0x12:
>> 76fdfc52 83c404 add esp,4
>>
>> 0:000> k
>> ChildEBP RetAddr
>> 000cf760 7701a2d4 ntdll!ZwTerminateProcess+0x12
>> 000cf77c 76827362 ntdll!RtlExitUserProcess+0x85
>> 000cf790 754b36dc kernel32!ExitProcessStub+0x12
>> 000cf79c 754b3371 msvcrt! crtExitProcess+0x17
>> 000cf7d4 754b36bb msvcrt!doexit+0xac
>> 000cf7e8 00d0144a msvcrt!exit+0x11
>> 000cf820 76823677 simple! wmainCRTStartup+0x117
>> 000cf82c 76ff9e12 kernel32!BaseThreadInitThunk+0xe
>> 000cf86c 76ff9de5 ntdll!__RtlUserThreadStart+0x70
>> 000cf884 00000000 ntdll!_RtlUserThreadStart+0x1b
>>
>> 0:000> q
>> quit:
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com [mailto:
xxxxx@lists.osr.com] On Behalf Of Don Burn
>> Sent: Wednesday, September 08, 2010 03:26 PM
>> To: Kernel Debugging Interest List
>> Subject: Re:[windbg] Using WinDbg on application-level code
>>
>> Joe,
>>
>> I you are using the kernel mode Windbg setup to debug a user mode
program, you either need a hardcoded breakpoint in the program, or there is
a magic command in Windbg which I can never remember. Personally, I just
code the breakpoint.
>>
>>
>> Don Burn (MVP, Windows DKD)
>> Windows Filesystem and Driver Consulting
>> Website: http://www.windrvr.com
>> Blog: http://msmvps.com/blogs/WinDrvr
>>
>>
>>
>>
>> “Joseph M. Newcomer” wrote in message
>> news:xxxxx@windbg:
>>
>> > As a piece of curiosity, and to allow me to demonstrate something, I
>> > was investigating the use of WinDbg in debugging user-level
>> > applications. I created a truly-trivial hello-world equivalent,
>> > started WinDbg, did an “Open Executable”, and ran it. Sure enough, it
>> > popped up a console window and the output came out.
>> >
>> > So I tried to set a breakpoint. It didn’t work. Odd. So I started
>> > single-stepping, and found myself in code I didn’t recognize as
>> > belonging to my program. Odd. In fact, I found myself in NTDLL.DLL,
without symbols.
>> > Odder. So I set up a pointer to the msdl symbols server. Still no
>> > luck; it appears either the symbol server doesn’t support ntdll.dll in
>> > user mode or I did something else wrong (but I copied-and-pasted the
>> > line from a version of WinDbg I use for analyzing crash dumps, where
>> > it does work, at least for the kernel). .reload did nothing.
>> > Ultimately, it looked like it was executing code that would cause my
>> > program to run, rather than executing my program’s code. Odder still.
>> >
>> > Did I miss something essential about using WinDbg for applications?
>> > (This is entirely possible, as I normally only use it for driver work,
>> > where I have only the usual and familiar problems with it).
>> > joe
>>
>>
>> —
>> WINDBG is sponsored by OSR
>>
>> 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
>
>
> —
> WINDBG is sponsored by OSR
>
> 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

Don_Burn_1 · September 8, 2010, 7:16pm

Martin,

He is directly invoking Windbg to debug the executable. I was
asking Joe if he was doing that or trying to use the kernel debugging
and the invoke the application on the remote machine. I assure you the
tricks you have to use are quite different.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“MARTIN OBRIEN” wrote in message
news:xxxxx@windbg:

> He didn’t - he opened an executive.
>
> On Sep 8, 2010 7:07 PM, “Don Burn” wrote:
> > And the output below is for using Windbg as a user space debugger. If
> > you have it setup for kernel mode debugging this does not work.
> >
> >
> > Don Burn (MVP, Windows DKD)
> > Windows Filesystem and Driver Consulting
> > Website: http://www.windrvr.com
> > Blog: http://msmvps.com/blogs/WinDrvr
> >
> >
> >
> >
> > “Jen-Lung Chiu” wrote in message
> > news:xxxxx@windbg:
> >
> >> Don’t think you need to code the breakpoint. WINDBG is quite capable as
> user-mode debugger. Below is debugger spew when debug the “Hello World” app,
> it sets a breakpoint at the start of wmain(), hits the breakpoints, then
> continues execution.
> >>
> >> Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
> >> Copyright (c) Microsoft Corporation. All rights reserved.
> >>
> >> CommandLine: \dbg\test\Simple\objfre\i386\simple.exe
> >> Symbol search path is: srvhttp://msdl.microsoft.com/download/symbols
> >> Executable search path is:
> >> ModLoad: 00d00000 00d05000 simple.exe
> >> ModLoad: 76fc0000 77140000 ntdll.dll
> >> ModLoad: 76810000 76910000 E:\Windows\syswow64\kernel32.dll
> >> ModLoad: 763f0000 76436000 E:\Windows\syswow64\KERNELBASE.dll
> >> ModLoad: 754a0000 7554c000 E:\Windows\syswow64\msvcrt.dll
> >> (82c.1358): Break instruction exception - code 80000003 (first chance)
> >> eax=00000000 ebx=00000000 ecx=9ea30000 edx=0020df38 esi=fffffffe
> edi=76fe3b90
> >> eip=77060b2d esp=000cf3a4 ebp=000cf3d0 iopl=0 nv up ei pl zr na pe nc
> >> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
> >> ntdll!LdrpDoDebuggerBreak+0x2c:
> >> 77060b2d cc int 3
> >>
> >> 0:000> .reload /f
> >> Reloading current modules
> >> …
> >>
> >> 0:000> k
> >> ChildEBP RetAddr
> >> 000cf3d0 770412e9 ntdll!LdrpDoDebuggerBreak+0x2c
> >> 000cf548 7701209f ntdll!LdrpInitializeProcess+0x132f
> >> 000cf598 76ff9d99 ntdll!_LdrpInitialize+0x78
> >> 000cf5a8 00000000 ntdll!LdrInitializeThunk+0x10
> >>
> >> 0:000> x simple!wmain
> >> 006311f0 simple!wmain (int, unsigned short **)
> >> 006314a0 simple!wmainCRTStartup (void)
> >>
> >> 0:000> bp simple!wmain
> >>
> >> 0:000> g
> >> Breakpoint 0 hit
> >> eax=000d0000 ebx=00000000 ecx=00d03674 edx=00000000 esi=00000001
> edi=00000000
> >> eip=00d011f0 esp=000cf7e4 ebp=000cf820 iopl=0 nv up ei pl zr na pe nc
> >> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
> >> simple!wmain:
> >> 00d011f0 8bff mov edi,edi
> >>
> >> 0:000> k
> >> ChildEBP RetAddr
> >> 000cf7e0 00d01433 simple!wmain
> >> 000cf820 76823677 simple! wmainCRTStartup+0x100
> >> 000cf82c 76ff9e12 kernel32!BaseThreadInitThunk+0xe
> >> 000cf86c 76ff9de5 ntdll! RtlUserThreadStart+0x70
> >> 000cf884 00000000 ntdll!_RtlUserThreadStart+0x1b
> >>
> >> 0:000> g
> >> Hello world
> >> eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=770c2100
> edi=770c20c0
> >> eip=76fdfc52 esp=000cf760 ebp=000cf77c iopl=0 nv up ei pl nz na po nc
> >> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
> >> ntdll!ZwTerminateProcess+0x12:
> >> 76fdfc52 83c404 add esp,4
> >>
> >> 0:000> k
> >> ChildEBP RetAddr
> >> 000cf760 7701a2d4 ntdll!ZwTerminateProcess+0x12
> >> 000cf77c 76827362 ntdll!RtlExitUserProcess+0x85
> >> 000cf790 754b36dc kernel32!ExitProcessStub+0x12
> >> 000cf79c 754b3371 msvcrt! crtExitProcess+0x17
> >> 000cf7d4 754b36bb msvcrt!doexit+0xac
> >> 000cf7e8 00d0144a msvcrt!exit+0x11
> >> 000cf820 76823677 simple! wmainCRTStartup+0x117
> >> 000cf82c 76ff9e12 kernel32!BaseThreadInitThunk+0xe
> >> 000cf86c 76ff9de5 ntdll!__RtlUserThreadStart+0x70
> >> 000cf884 00000000 ntdll!_RtlUserThreadStart+0x1b
> >>
> >> 0:000> q
> >> quit:
> >>
> >> -----Original Message-----
> >> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of Don Burn
> >> Sent: Wednesday, September 08, 2010 03:26 PM
> >> To: Kernel Debugging Interest List
> >> Subject: Re:[windbg] Using WinDbg on application-level code
> >>
> >> Joe,
> >>
> >> I you are using the kernel mode Windbg setup to debug a user mode
> program, you either need a hardcoded breakpoint in the program, or there is
> a magic command in Windbg which I can never remember. Personally, I just
> code the breakpoint.
> >>
> >>
> >> Don Burn (MVP, Windows DKD)
> >> Windows Filesystem and Driver Consulting
> >> Website: http://www.windrvr.com
> >> Blog: http://msmvps.com/blogs/WinDrvr
> >>
> >>
> >>
> >>
> >> “Joseph M. Newcomer” wrote in message
> >> news:xxxxx@windbg:
> >>
> >> > As a piece of curiosity, and to allow me to demonstrate something, I
> >> > was investigating the use of WinDbg in debugging user-level
> >> > applications. I created a truly-trivial hello-world equivalent,
> >> > started WinDbg, did an “Open Executable”, and ran it. Sure enough, it
> >> > popped up a console window and the output came out.
> >> >
> >> > So I tried to set a breakpoint. It didn’t work. Odd. So I started
> >> > single-stepping, and found myself in code I didn’t recognize as
> >> > belonging to my program. Odd. In fact, I found myself in NTDLL.DLL,
> without symbols.
> >> > Odder. So I set up a pointer to the msdl symbols server. Still no
> >> > luck; it appears either the symbol server doesn’t support ntdll.dll in
> >> > user mode or I did something else wrong (but I copied-and-pasted the
> >> > line from a version of WinDbg I use for analyzing crash dumps, where
> >> > it does work, at least for the kernel). .reload did nothing.
> >> > Ultimately, it looked like it was executing code that would cause my
> >> > program to run, rather than executing my program’s code. Odder still.
> >> >
> >> > Did I miss something essential about using WinDbg for applications?
> >> > (This is entirely possible, as I normally only use it for driver work,
> >> > where I have only the usual and familiar problems with it).
> >> > joe
> >>
> >>
> >> —
> >> WINDBG is sponsored by OSR
> >>
> >> 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
> >
> >
> > —
> > WINDBG is sponsored by OSR
> >
> > 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

Ken_Johnson · September 8, 2010, 7:41pm

The “Open Executable” menu item initiates local user mode debugging, not kd.

S

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Wednesday, September 08, 2010 4:16 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] RE:Re:Using WinDbg on application-level code

Martin,

He is directly invoking Windbg to debug the executable. I was asking Joe if he was doing that or trying to use the kernel debugging and the invoke the application on the remote machine. I assure you the tricks you have to use are quite different.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“MARTIN OBRIEN” wrote in message
news:xxxxx@windbg:

> He didn’t - he opened an executive.
>
> On Sep 8, 2010 7:07 PM, “Don Burn” wrote:
> > And the output below is for using Windbg as a user space debugger.
> > If you have it setup for kernel mode debugging this does not work.
> >
> >
> > Don Burn (MVP, Windows DKD)
> > Windows Filesystem and Driver Consulting
> > Website: http://www.windrvr.com
> > Blog: http://msmvps.com/blogs/WinDrvr
> >
> >
> >
> >
> > “Jen-Lung Chiu” wrote in message
> > news:xxxxx@windbg:
> >
> >> Don’t think you need to code the breakpoint. WINDBG is quite
> >> capable as
> user-mode debugger. Below is debugger spew when debug the “Hello
> World” app, it sets a breakpoint at the start of wmain(), hits the
> breakpoints, then continues execution.
> >>
> >> Microsoft (R) Windows Debugger Version 6.12.0002.633 X86 Copyright
> >> (c) Microsoft Corporation. All rights reserved.
> >>
> >> CommandLine: \dbg\test\Simple\objfre\i386\simple.exe
> >> Symbol search path is:
> >> srvhttp://msdl.microsoft.com/download/symbols
> >> Executable search path is:
> >> ModLoad: 00d00000 00d05000 simple.exe
> >> ModLoad: 76fc0000 77140000 ntdll.dll
> >> ModLoad: 76810000 76910000 E:\Windows\syswow64\kernel32.dll
> >> ModLoad: 763f0000 76436000 E:\Windows\syswow64\KERNELBASE.dll
> >> ModLoad: 754a0000 7554c000 E:\Windows\syswow64\msvcrt.dll
> >> (82c.1358): Break instruction exception - code 80000003 (first
> >> chance)
> >> eax=00000000 ebx=00000000 ecx=9ea30000 edx=0020df38 esi=fffffffe
> edi=76fe3b90
> >> eip=77060b2d esp=000cf3a4 ebp=000cf3d0 iopl=0 nv up ei pl zr na pe
> >> nc
> >> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
> >> ntdll!LdrpDoDebuggerBreak+0x2c:
> >> 77060b2d cc int 3
> >>
> >> 0:000> .reload /f
> >> Reloading current modules
> >> …
> >>
> >> 0:000> k
> >> ChildEBP RetAddr
> >> 000cf3d0 770412e9 ntdll!LdrpDoDebuggerBreak+0x2c
> >> 000cf548 7701209f ntdll!LdrpInitializeProcess+0x132f
> >> 000cf598 76ff9d99 ntdll!_LdrpInitialize+0x78
> >> 000cf5a8 00000000 ntdll!LdrInitializeThunk+0x10
> >>
> >> 0:000> x simple!wmain
> >> 006311f0 simple!wmain (int, unsigned short **)
> >> 006314a0 simple!wmainCRTStartup (void)
> >>
> >> 0:000> bp simple!wmain
> >>
> >> 0:000> g
> >> Breakpoint 0 hit
> >> eax=000d0000 ebx=00000000 ecx=00d03674 edx=00000000 esi=00000001
> edi=00000000
> >> eip=00d011f0 esp=000cf7e4 ebp=000cf820 iopl=0 nv up ei pl zr na pe
> >> nc
> >> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
> >> simple!wmain:
> >> 00d011f0 8bff mov edi,edi
> >>
> >> 0:000> k
> >> ChildEBP RetAddr
> >> 000cf7e0 00d01433 simple!wmain
> >> 000cf820 76823677 simple! wmainCRTStartup+0x100 000cf82c 76ff9e12
> >> kernel32!BaseThreadInitThunk+0xe 000cf86c 76ff9de5
> >> ntdll! RtlUserThreadStart+0x70
> >> 000cf884 00000000 ntdll!_RtlUserThreadStart+0x1b
> >>
> >> 0:000> g
> >> Hello world
> >> eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=770c2100
> edi=770c20c0
> >> eip=76fdfc52 esp=000cf760 ebp=000cf77c iopl=0 nv up ei pl nz na po
> >> nc
> >> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
> >> ntdll!ZwTerminateProcess+0x12:
> >> 76fdfc52 83c404 add esp,4
> >>
> >> 0:000> k
> >> ChildEBP RetAddr
> >> 000cf760 7701a2d4 ntdll!ZwTerminateProcess+0x12 000cf77c 76827362
> >> ntdll!RtlExitUserProcess+0x85
> >> 000cf790 754b36dc kernel32!ExitProcessStub+0x12 000cf79c 754b3371
> >> msvcrt! crtExitProcess+0x17
> >> 000cf7d4 754b36bb msvcrt!doexit+0xac
> >> 000cf7e8 00d0144a msvcrt!exit+0x11
> >> 000cf820 76823677 simple! wmainCRTStartup+0x117 000cf82c 76ff9e12
> >> kernel32!BaseThreadInitThunk+0xe 000cf86c 76ff9de5
> >> ntdll!__RtlUserThreadStart+0x70
> >> 000cf884 00000000 ntdll!_RtlUserThreadStart+0x1b
> >>
> >> 0:000> q
> >> quit:
> >>
> >> -----Original Message-----
> >> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of Don Burn
> >> Sent: Wednesday, September 08, 2010 03:26 PM
> >> To: Kernel Debugging Interest List
> >> Subject: Re:[windbg] Using WinDbg on application-level code
> >>
> >> Joe,
> >>
> >> I you are using the kernel mode Windbg setup to debug a user mode
> program, you either need a hardcoded breakpoint in the program, or
> there is a magic command in Windbg which I can never remember.
> Personally, I just code the breakpoint.
> >>
> >>
> >> Don Burn (MVP, Windows DKD)
> >> Windows Filesystem and Driver Consulting
> >> Website: http://www.windrvr.com
> >> Blog: http://msmvps.com/blogs/WinDrvr
> >>
> >>
> >>
> >>
> >> “Joseph M. Newcomer” wrote in message
> >> news:xxxxx@windbg:
> >>
> >> > As a piece of curiosity, and to allow me to demonstrate
> >> > something, I was investigating the use of WinDbg in debugging
> >> > user-level applications. I created a truly-trivial hello-world
> >> > equivalent, started WinDbg, did an “Open Executable”, and ran it.
> >> > Sure enough, it popped up a console window and the output came out.
> >> >
> >> > So I tried to set a breakpoint. It didn’t work. Odd. So I started
> >> > single-stepping, and found myself in code I didn’t recognize as
> >> > belonging to my program. Odd. In fact, I found myself in
> >> > NTDLL.DLL,
> without symbols.
> >> > Odder. So I set up a pointer to the msdl symbols server. Still no
> >> > luck; it appears either the symbol server doesn’t support
> >> > ntdll.dll in user mode or I did something else wrong (but I
> >> > copied-and-pasted the line from a version of WinDbg I use for
> >> > analyzing crash dumps, where it does work, at least for the kernel). .reload did nothing.
> >> > Ultimately, it looked like it was executing code that would
> >> > cause my program to run, rather than executing my program’s code. Odder still.
> >> >
> >> > Did I miss something essential about using WinDbg for applications?
> >> > (This is entirely possible, as I normally only use it for driver
> >> > work, where I have only the usual and familiar problems with it).
> >> > joe
> >>
> >>
> >> —
> >> WINDBG is sponsored by OSR
> >>
> >> 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
> >
> >
> > —
> > WINDBG is sponsored by OSR
> >
> > 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

—
WINDBG is sponsored by OSR

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

OSR_Community_User · September 8, 2010, 9:22pm

The documentation is unclear, as am I, about what this means. If I want to
run a program under WinDbg, what is the magical incantation?
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Wednesday, September 08, 2010 7:40 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] RE:Re:Using WinDbg on application-level code

The “Open Executable” menu item initiates local user mode debugging, not kd.

S

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Wednesday, September 08, 2010 4:16 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] RE:Re:Using WinDbg on application-level code

Martin,

He is directly invoking Windbg to debug the executable. I was asking
Joe if he was doing that or trying to use the kernel debugging and the
invoke the application on the remote machine. I assure you the tricks you
have to use are quite different.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“MARTIN OBRIEN” wrote in message
news:xxxxx@windbg:

> He didn’t - he opened an executive.
>
> On Sep 8, 2010 7:07 PM, “Don Burn” wrote:
> > And the output below is for using Windbg as a user space debugger.
> > If you have it setup for kernel mode debugging this does not work.
> >
> >
> > Don Burn (MVP, Windows DKD)
> > Windows Filesystem and Driver Consulting
> > Website: http://www.windrvr.com
> > Blog: http://msmvps.com/blogs/WinDrvr
> >
> >
> >
> >
> > “Jen-Lung Chiu” wrote in message
> > news:xxxxx@windbg:
> >
> >> Don’t think you need to code the breakpoint. WINDBG is quite
> >> capable as
> user-mode debugger. Below is debugger spew when debug the “Hello
> World” app, it sets a breakpoint at the start of wmain(), hits the
> breakpoints, then continues execution.
> >>
> >> Microsoft (R) Windows Debugger Version 6.12.0002.633 X86 Copyright
> >> (c) Microsoft Corporation. All rights reserved.
> >>
> >> CommandLine: \dbg\test\Simple\objfre\i386\simple.exe
> >> Symbol search path is:
> >> srvhttp://msdl.microsoft.com/download/symbols
> >> Executable search path is:
> >> ModLoad: 00d00000 00d05000 simple.exe
> >> ModLoad: 76fc0000 77140000 ntdll.dll
> >> ModLoad: 76810000 76910000 E:\Windows\syswow64\kernel32.dll
> >> ModLoad: 763f0000 76436000 E:\Windows\syswow64\KERNELBASE.dll
> >> ModLoad: 754a0000 7554c000 E:\Windows\syswow64\msvcrt.dll
> >> (82c.1358): Break instruction exception - code 80000003 (first
> >> chance)
> >> eax=00000000 ebx=00000000 ecx=9ea30000 edx=0020df38 esi=fffffffe
> edi=76fe3b90
> >> eip=77060b2d esp=000cf3a4 ebp=000cf3d0 iopl=0 nv up ei pl zr na pe
> >> nc
> >> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
> >> ntdll!LdrpDoDebuggerBreak+0x2c:
> >> 77060b2d cc int 3
> >>
> >> 0:000> .reload /f
> >> Reloading current modules
> >> …
> >>
> >> 0:000> k
> >> ChildEBP RetAddr
> >> 000cf3d0 770412e9 ntdll!LdrpDoDebuggerBreak+0x2c
> >> 000cf548 7701209f ntdll!LdrpInitializeProcess+0x132f
> >> 000cf598 76ff9d99 ntdll!_LdrpInitialize+0x78
> >> 000cf5a8 00000000 ntdll!LdrInitializeThunk+0x10
> >>
> >> 0:000> x simple!wmain
> >> 006311f0 simple!wmain (int, unsigned short **)
> >> 006314a0 simple!wmainCRTStartup (void)
> >>
> >> 0:000> bp simple!wmain
> >>
> >> 0:000> g
> >> Breakpoint 0 hit
> >> eax=000d0000 ebx=00000000 ecx=00d03674 edx=00000000 esi=00000001
> edi=00000000
> >> eip=00d011f0 esp=000cf7e4 ebp=000cf820 iopl=0 nv up ei pl zr na pe
> >> nc
> >> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
> >> simple!wmain:
> >> 00d011f0 8bff mov edi,edi
> >>
> >> 0:000> k
> >> ChildEBP RetAddr
> >> 000cf7e0 00d01433 simple!wmain
> >> 000cf820 76823677 simple! wmainCRTStartup+0x100 000cf82c 76ff9e12
> >> kernel32!BaseThreadInitThunk+0xe 000cf86c 76ff9de5
> >> ntdll! RtlUserThreadStart+0x70
> >> 000cf884 00000000 ntdll!_RtlUserThreadStart+0x1b
> >>
> >> 0:000> g
> >> Hello world
> >> eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=770c2100
> edi=770c20c0
> >> eip=76fdfc52 esp=000cf760 ebp=000cf77c iopl=0 nv up ei pl nz na po
> >> nc
> >> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
> >> ntdll!ZwTerminateProcess+0x12:
> >> 76fdfc52 83c404 add esp,4
> >>
> >> 0:000> k
> >> ChildEBP RetAddr
> >> 000cf760 7701a2d4 ntdll!ZwTerminateProcess+0x12 000cf77c 76827362
> >> ntdll!RtlExitUserProcess+0x85
> >> 000cf790 754b36dc kernel32!ExitProcessStub+0x12 000cf79c 754b3371
> >> msvcrt! crtExitProcess+0x17
> >> 000cf7d4 754b36bb msvcrt!doexit+0xac
> >> 000cf7e8 00d0144a msvcrt!exit+0x11
> >> 000cf820 76823677 simple! wmainCRTStartup+0x117 000cf82c 76ff9e12
> >> kernel32!BaseThreadInitThunk+0xe 000cf86c 76ff9de5
> >> ntdll!__RtlUserThreadStart+0x70
> >> 000cf884 00000000 ntdll!_RtlUserThreadStart+0x1b
> >>
> >> 0:000> q
> >> quit:
> >>
> >> -----Original Message-----
> >> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of Don Burn
> >> Sent: Wednesday, September 08, 2010 03:26 PM
> >> To: Kernel Debugging Interest List
> >> Subject: Re:[windbg] Using WinDbg on application-level code
> >>
> >> Joe,
> >>
> >> I you are using the kernel mode Windbg setup to debug a user mode
> program, you either need a hardcoded breakpoint in the program, or
> there is a magic command in Windbg which I can never remember.
> Personally, I just code the breakpoint.
> >>
> >>
> >> Don Burn (MVP, Windows DKD)
> >> Windows Filesystem and Driver Consulting
> >> Website: http://www.windrvr.com
> >> Blog: http://msmvps.com/blogs/WinDrvr
> >>
> >>
> >>
> >>
> >> “Joseph M. Newcomer” wrote in message
> >> news:xxxxx@windbg:
> >>
> >> > As a piece of curiosity, and to allow me to demonstrate
> >> > something, I was investigating the use of WinDbg in debugging
> >> > user-level applications. I created a truly-trivial hello-world
> >> > equivalent, started WinDbg, did an “Open Executable”, and ran it.
> >> > Sure enough, it popped up a console window and the output came out.
> >> >
> >> > So I tried to set a breakpoint. It didn’t work. Odd. So I started
> >> > single-stepping, and found myself in code I didn’t recognize as
> >> > belonging to my program. Odd. In fact, I found myself in
> >> > NTDLL.DLL,
> without symbols.
> >> > Odder. So I set up a pointer to the msdl symbols server. Still no
> >> > luck; it appears either the symbol server doesn’t support
> >> > ntdll.dll in user mode or I did something else wrong (but I
> >> > copied-and-pasted the line from a version of WinDbg I use for
> >> > analyzing crash dumps, where it does work, at least for the kernel).
.reload did nothing.
> >> > Ultimately, it looked like it was executing code that would
> >> > cause my program to run, rather than executing my program’s code.
Odder still.
> >> >
> >> > Did I miss something essential about using WinDbg for applications?
> >> > (This is entirely possible, as I normally only use it for driver
> >> > work, where I have only the usual and familiar problems with it).
> >> > joe
> >>
> >>
> >> —
> >> WINDBG is sponsored by OSR
> >>
> >> 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
> >
> >
> > —
> > WINDBG is sponsored by OSR
> >
> > 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

—
WINDBG is sponsored by OSR

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

—
WINDBG is sponsored by OSR

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

–
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

OSR_Community_User · September 8, 2010, 9:26pm

I do this all the time. I just do open executable and I get a breakpoint somewhere in NTDLL. I then set a breakpoint in my executable and hit go. I am then in my image and can set whatever other breakpoints I need.

–Mark Cariddi
OSR Open Systems Resources ,Inc.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Joseph M. Newcomer
Sent: Wednesday, September 08, 2010 9:22 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] RE:Re:Using WinDbg on application-level code

The documentation is unclear, as am I, about what this means. If I want to run a program under WinDbg, what is the magical incantation?
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Wednesday, September 08, 2010 7:40 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] RE:Re:Using WinDbg on application-level code

The “Open Executable” menu item initiates local user mode debugging, not kd.

S

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Wednesday, September 08, 2010 4:16 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] RE:Re:Using WinDbg on application-level code

Martin,

He is directly invoking Windbg to debug the executable. I was asking Joe if he was doing that or trying to use the kernel debugging and the invoke the application on the remote machine. I assure you the tricks you have to use are quite different.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“MARTIN OBRIEN” wrote in message
news:xxxxx@windbg:

> He didn’t - he opened an executive.
>
> On Sep 8, 2010 7:07 PM, “Don Burn” wrote:
> > And the output below is for using Windbg as a user space debugger.
> > If you have it setup for kernel mode debugging this does not work.
> >
> >
> > Don Burn (MVP, Windows DKD)
> > Windows Filesystem and Driver Consulting
> > Website: http://www.windrvr.com
> > Blog: http://msmvps.com/blogs/WinDrvr
> >
> >
> >
> >
> > “Jen-Lung Chiu” wrote in message
> > news:xxxxx@windbg:
> >
> >> Don’t think you need to code the breakpoint. WINDBG is quite
> >> capable as
> user-mode debugger. Below is debugger spew when debug the “Hello
> World” app, it sets a breakpoint at the start of wmain(), hits the
> breakpoints, then continues execution.
> >>
> >> Microsoft (R) Windows Debugger Version 6.12.0002.633 X86 Copyright
> >> (c) Microsoft Corporation. All rights reserved.
> >>
> >> CommandLine: \dbg\test\Simple\objfre\i386\simple.exe
> >> Symbol search path is:
> >> srvhttp://msdl.microsoft.com/download/symbols
> >> Executable search path is:
> >> ModLoad: 00d00000 00d05000 simple.exe
> >> ModLoad: 76fc0000 77140000 ntdll.dll
> >> ModLoad: 76810000 76910000 E:\Windows\syswow64\kernel32.dll
> >> ModLoad: 763f0000 76436000 E:\Windows\syswow64\KERNELBASE.dll
> >> ModLoad: 754a0000 7554c000 E:\Windows\syswow64\msvcrt.dll
> >> (82c.1358): Break instruction exception - code 80000003 (first
> >> chance)
> >> eax=00000000 ebx=00000000 ecx=9ea30000 edx=0020df38 esi=fffffffe
> edi=76fe3b90
> >> eip=77060b2d esp=000cf3a4 ebp=000cf3d0 iopl=0 nv up ei pl zr na pe
> >> nc
> >> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
> >> ntdll!LdrpDoDebuggerBreak+0x2c:
> >> 77060b2d cc int 3
> >>
> >> 0:000> .reload /f
> >> Reloading current modules
> >> …
> >>
> >> 0:000> k
> >> ChildEBP RetAddr
> >> 000cf3d0 770412e9 ntdll!LdrpDoDebuggerBreak+0x2c
> >> 000cf548 7701209f ntdll!LdrpInitializeProcess+0x132f
> >> 000cf598 76ff9d99 ntdll!_LdrpInitialize+0x78
> >> 000cf5a8 00000000 ntdll!LdrInitializeThunk+0x10
> >>
> >> 0:000> x simple!wmain
> >> 006311f0 simple!wmain (int, unsigned short **)
> >> 006314a0 simple!wmainCRTStartup (void)
> >>
> >> 0:000> bp simple!wmain
> >>
> >> 0:000> g
> >> Breakpoint 0 hit
> >> eax=000d0000 ebx=00000000 ecx=00d03674 edx=00000000 esi=00000001
> edi=00000000
> >> eip=00d011f0 esp=000cf7e4 ebp=000cf820 iopl=0 nv up ei pl zr na pe
> >> nc
> >> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
> >> simple!wmain:
> >> 00d011f0 8bff mov edi,edi
> >>
> >> 0:000> k
> >> ChildEBP RetAddr
> >> 000cf7e0 00d01433 simple!wmain
> >> 000cf820 76823677 simple! wmainCRTStartup+0x100 000cf82c 76ff9e12
> >> kernel32!BaseThreadInitThunk+0xe 000cf86c 76ff9de5
> >> ntdll! RtlUserThreadStart+0x70
> >> 000cf884 00000000 ntdll!_RtlUserThreadStart+0x1b
> >>
> >> 0:000> g
> >> Hello world
> >> eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=770c2100
> edi=770c20c0
> >> eip=76fdfc52 esp=000cf760 ebp=000cf77c iopl=0 nv up ei pl nz na po
> >> nc
> >> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
> >> ntdll!ZwTerminateProcess+0x12:
> >> 76fdfc52 83c404 add esp,4
> >>
> >> 0:000> k
> >> ChildEBP RetAddr
> >> 000cf760 7701a2d4 ntdll!ZwTerminateProcess+0x12 000cf77c 76827362
> >> ntdll!RtlExitUserProcess+0x85
> >> 000cf790 754b36dc kernel32!ExitProcessStub+0x12 000cf79c 754b3371
> >> msvcrt! crtExitProcess+0x17
> >> 000cf7d4 754b36bb msvcrt!doexit+0xac
> >> 000cf7e8 00d0144a msvcrt!exit+0x11
> >> 000cf820 76823677 simple! wmainCRTStartup+0x117 000cf82c 76ff9e12
> >> kernel32!BaseThreadInitThunk+0xe 000cf86c 76ff9de5
> >> ntdll!__RtlUserThreadStart+0x70
> >> 000cf884 00000000 ntdll!_RtlUserThreadStart+0x1b
> >>
> >> 0:000> q
> >> quit:
> >>
> >> -----Original Message-----
> >> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of Don Burn
> >> Sent: Wednesday, September 08, 2010 03:26 PM
> >> To: Kernel Debugging Interest List
> >> Subject: Re:[windbg] Using WinDbg on application-level code
> >>
> >> Joe,
> >>
> >> I you are using the kernel mode Windbg setup to debug a user mode
> program, you either need a hardcoded breakpoint in the program, or
> there is a magic command in Windbg which I can never remember.
> Personally, I just code the breakpoint.
> >>
> >>
> >> Don Burn (MVP, Windows DKD)
> >> Windows Filesystem and Driver Consulting
> >> Website: http://www.windrvr.com
> >> Blog: http://msmvps.com/blogs/WinDrvr
> >>
> >>
> >>
> >>
> >> “Joseph M. Newcomer” wrote in message
> >> news:xxxxx@windbg:
> >>
> >> > As a piece of curiosity, and to allow me to demonstrate
> >> > something, I was investigating the use of WinDbg in debugging
> >> > user-level applications. I created a truly-trivial hello-world
> >> > equivalent, started WinDbg, did an “Open Executable”, and ran it.
> >> > Sure enough, it popped up a console window and the output came out.
> >> >
> >> > So I tried to set a breakpoint. It didn’t work. Odd. So I started
> >> > single-stepping, and found myself in code I didn’t recognize as
> >> > belonging to my program. Odd. In fact, I found myself in
> >> > NTDLL.DLL,
> without symbols.
> >> > Odder. So I set up a pointer to the msdl symbols server. Still no
> >> > luck; it appears either the symbol server doesn’t support
> >> > ntdll.dll in user mode or I did something else wrong (but I
> >> > copied-and-pasted the line from a version of WinDbg I use for
> >> > analyzing crash dumps, where it does work, at least for the kernel).
.reload did nothing.
> >> > Ultimately, it looked like it was executing code that would
> >> > cause my program to run, rather than executing my program’s code.
Odder still.
> >> >
> >> > Did I miss something essential about using WinDbg for applications?
> >> > (This is entirely possible, as I normally only use it for driver
> >> > work, where I have only the usual and familiar problems with it).
> >> > joe
> >>
> >>
> >> —
> >> WINDBG is sponsored by OSR
> >>
> >> 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
> >
> >
> > —
> > WINDBG is sponsored by OSR
> >
> > 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

—
WINDBG is sponsored by OSR

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

—
WINDBG is sponsored by OSR

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

–
This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

—
WINDBG is sponsored by OSR

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

OSR_Community_User · September 8, 2010, 9:26pm

But why is it necessary to invoke WinDbg from a command shell? I would like
to simply start WinDbg, then run the program I want to debug. This seems
like fairly elementary behavior for a debugger.
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jen-Lung Chiu
Sent: Wednesday, September 08, 2010 6:36 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] Using WinDbg on application-level code

Don’t think you need to code the breakpoint. WINDBG is quite capable as
user-mode debugger. Below is debugger spew when debug the “Hello World” app,
it sets a breakpoint at the start of wmain(), hits the breakpoints, then
continues execution.

CommandLine: \dbg\test\Simple\objfre\i386\simple.exe
Symbol search path is: srv*http://msdl.microsoft.com/download/symbols
Executable search path is:
ModLoad: 00d00000 00d05000 simple.exe
ModLoad: 76fc0000 77140000 ntdll.dll
ModLoad: 76810000 76910000 E:\Windows\syswow64\kernel32.dll
ModLoad: 763f0000 76436000 E:\Windows\syswow64\KERNELBASE.dll
ModLoad: 754a0000 7554c000 E:\Windows\syswow64\msvcrt.dll
(82c.1358): Break instruction exception - code 80000003 (first chance)
eax=00000000 ebx=00000000 ecx=9ea30000 edx=0020df38 esi=fffffffe
edi=76fe3b90
eip=77060b2d esp=000cf3a4 ebp=000cf3d0 iopl=0 nv up ei pl zr na pe
nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b
efl=00000246
ntdll!LdrpDoDebuggerBreak+0x2c:
77060b2d cc int 3

0:000> .reload /f
Reloading current modules
…

0:000> k
ChildEBP RetAddr
000cf3d0 770412e9 ntdll!LdrpDoDebuggerBreak+0x2c
000cf548 7701209f ntdll!LdrpInitializeProcess+0x132f
000cf598 76ff9d99 ntdll!_LdrpInitialize+0x78
000cf5a8 00000000 ntdll!LdrInitializeThunk+0x10

0:000> x simple!wmain*
006311f0 simple!wmain (int, unsigned short **)
006314a0 simple!wmainCRTStartup (void)

0:000> bp simple!wmain

0:000> g
Breakpoint 0 hit
eax=000d0000 ebx=00000000 ecx=00d03674 edx=00000000 esi=00000001
edi=00000000
eip=00d011f0 esp=000cf7e4 ebp=000cf820 iopl=0 nv up ei pl zr na pe
nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b
efl=00000246
simple!wmain:
00d011f0 8bff mov edi,edi

0:000> k
ChildEBP RetAddr
000cf7e0 00d01433 simple!wmain
000cf820 76823677 simple!__wmainCRTStartup+0x100
000cf82c 76ff9e12 kernel32!BaseThreadInitThunk+0xe
000cf86c 76ff9de5 ntdll!__RtlUserThreadStart+0x70
000cf884 00000000 ntdll!_RtlUserThreadStart+0x1b

0:000> g
Hello world
eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=770c2100
edi=770c20c0
eip=76fdfc52 esp=000cf760 ebp=000cf77c iopl=0 nv up ei pl nz na po
nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b
efl=00000202
ntdll!ZwTerminateProcess+0x12:
76fdfc52 83c404 add esp,4

0:000> k
ChildEBP RetAddr
000cf760 7701a2d4 ntdll!ZwTerminateProcess+0x12
000cf77c 76827362 ntdll!RtlExitUserProcess+0x85
000cf790 754b36dc kernel32!ExitProcessStub+0x12
000cf79c 754b3371 msvcrt!__crtExitProcess+0x17
000cf7d4 754b36bb msvcrt!doexit+0xac
000cf7e8 00d0144a msvcrt!exit+0x11
000cf820 76823677 simple!__wmainCRTStartup+0x117
000cf82c 76ff9e12 kernel32!BaseThreadInitThunk+0xe
000cf86c 76ff9de5 ntdll!__RtlUserThreadStart+0x70
000cf884 00000000 ntdll!_RtlUserThreadStart+0x1b

0:000> q
quit:

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Wednesday, September 08, 2010 03:26 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Using WinDbg on application-level code

Joe,

I you are using the kernel mode Windbg setup to debug a user mode
program, you either need a hardcoded breakpoint in the program, or there is
a magic command in Windbg which I can never remember. Personally, I just
code the breakpoint.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“Joseph M. Newcomer” wrote in message
news:xxxxx@windbg:

> As a piece of curiosity, and to allow me to demonstrate something, I
> was investigating the use of WinDbg in debugging user-level
> applications. I created a truly-trivial hello-world equivalent,
> started WinDbg, did an “Open Executable”, and ran it. Sure enough, it
> popped up a console window and the output came out.
>
> So I tried to set a breakpoint. It didn’t work. Odd. So I started
> single-stepping, and found myself in code I didn’t recognize as
> belonging to my program. Odd. In fact, I found myself in NTDLL.DLL,
without symbols.
> Odder. So I set up a pointer to the msdl symbols server. Still no
> luck; it appears either the symbol server doesn’t support ntdll.dll in
> user mode or I did something else wrong (but I copied-and-pasted the
> line from a version of WinDbg I use for analyzing crash dumps, where
> it does work, at least for the kernel). .reload did nothing.
> Ultimately, it looked like it was executing code that would cause my
> program to run, rather than executing my program’s code. Odder still.
>
> Did I miss something essential about using WinDbg for applications?
> (This is entirely possible, as I normally only use it for driver work,
> where I have only the usual and familiar problems with it).
> joe

—
WINDBG is sponsored by OSR

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

—
WINDBG is sponsored by OSR

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

–
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

OSR_Community_User · September 8, 2010, 9:29pm

No, I’m just invoking WinDbg without any options (unlike for kernel mode,
where my shortcut has -k added at the end). I am not doing remote
debugging, but want to run the target program locally on the same machine
I’m running WinDbg on. Ideally, I want to start WinDbg, and say “run that
program over there, with a breakpoint set at XXXXXX” and have it run.

Every debugger I’ve used in the last 40 years or so works this way, so I was
trying to use WinDbg in the same fashion that I am used to (maybe this is
where I went wrong…)
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Wednesday, September 08, 2010 6:26 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Using WinDbg on application-level code

Joe,

I you are using the kernel mode Windbg setup to debug a user mode
program, you either need a hardcoded breakpoint in the program, or there
is a magic command in Windbg which I can never remember. Personally, I
just code the breakpoint.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“Joseph M. Newcomer” wrote in message
news:xxxxx@windbg:

> As a piece of curiosity, and to allow me to demonstrate something, I was
> investigating the use of WinDbg in debugging user-level applications. I
> created a truly-trivial hello-world equivalent, started WinDbg, did an
“Open
> Executable”, and ran it. Sure enough, it popped up a console window and
the
> output came out.
>
> So I tried to set a breakpoint. It didn’t work. Odd. So I started
> single-stepping, and found myself in code I didn’t recognize as belonging
to
> my program. Odd. In fact, I found myself in NTDLL.DLL, without symbols.
> Odder. So I set up a pointer to the msdl symbols server. Still no luck;
it
> appears either the symbol server doesn’t support ntdll.dll in user mode or
I
> did something else wrong (but I copied-and-pasted the line from a version
of
> WinDbg I use for analyzing crash dumps, where it does work, at least for
the
> kernel). .reload did nothing. Ultimately, it looked like it was
executing
> code that would cause my program to run, rather than executing my
> program’s code. Odder still.
>
> Did I miss something essential about using WinDbg for applications? (This
> is entirely possible, as I normally only use it for driver work, where I
> have only the usual and familiar problems with it).
> joe

—
WINDBG is sponsored by OSR

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

–
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

OSR_Community_User · September 8, 2010, 9:31pm

I am not setting a breakpoint; in fact, I want to do a single F8 and step
into the first instruction. The idea here is to consider showing the C/C++
initialization setup while also showing the use of WinDbg.

When I wanted to set a breakpoint, at “main” or “_main” or “test!main” or
“test!_main”, it couldn’t find the symbol.
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jen-Lung Chiu
Sent: Wednesday, September 08, 2010 6:24 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Using WinDbg on application-level code

Questions:

How do you set up the breakpoint?
Yes, please turn on symbols spew to get more information on symbols
loading. After setup the .sympath (or just run .symfix), “!sym noisy” then
“.reload /f” would do.

Please check http://msdn.microsoft.com/en-us/library/ff550949(v=VS.85).aspx
for more information on the initial breakpoint.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Joseph M. Newcomer
Sent: Wednesday, September 08, 2010 03:11 PM
To: Kernel Debugging Interest List
Subject: [windbg] Using WinDbg on application-level code

As a piece of curiosity, and to allow me to demonstrate something, I was
investigating the use of WinDbg in debugging user-level applications. I
created a truly-trivial hello-world equivalent, started WinDbg, did an “Open
Executable”, and ran it. Sure enough, it popped up a console window and the
output came out.

So I tried to set a breakpoint. It didn’t work. Odd. So I started
single-stepping, and found myself in code I didn’t recognize as belonging to
my program. Odd. In fact, I found myself in NTDLL.DLL, without symbols.
Odder. So I set up a pointer to the msdl symbols server. Still no luck; it
appears either the symbol server doesn’t support ntdll.dll in user mode or I
did something else wrong (but I copied-and-pasted the line from a version of
WinDbg I use for analyzing crash dumps, where it does work, at least for the
kernel). .reload did nothing. Ultimately, it looked like it was executing
code that would *cause* my program to run, rather than executing my
program’s code. Odder still.

Did I miss something essential about using WinDbg for applications? (This
is entirely possible, as I normally only use it for driver work, where I
have only the usual and familiar problems with it).
joe

WINDBG is sponsored by OSR

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

WINDBG is sponsored by OSR

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

–
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

mm1 · September 8, 2010, 9:35pm

Whoops - Outlook’s autocomplete got me:

THIS: > He didn’t - he opened an executive.

WAS SUPPOSED TO BE: > He didn’t - he opened an EXECUTABLE.

My bad,

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Wednesday, September 08, 2010 7:40 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] RE:Re:Using WinDbg on application-level code

The “Open Executable” menu item initiates local user mode debugging, not kd.

S

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Wednesday, September 08, 2010 4:16 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] RE:Re:Using WinDbg on application-level code

Martin,

He is directly invoking Windbg to debug the executable. I was asking
Joe if he was doing that or trying to use the kernel debugging and the
invoke the application on the remote machine. I assure you the tricks you
have to use are quite different.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“MARTIN OBRIEN” wrote in message
news:xxxxx@windbg:

> He didn’t - he opened an executive.
>
> On Sep 8, 2010 7:07 PM, “Don Burn” wrote:
> > And the output below is for using Windbg as a user space debugger.
> > If you have it setup for kernel mode debugging this does not work.
> >
> >
> > Don Burn (MVP, Windows DKD)
> > Windows Filesystem and Driver Consulting
> > Website: http://www.windrvr.com
> > Blog: http://msmvps.com/blogs/WinDrvr
> >
> >
> >
> >
> > “Jen-Lung Chiu” wrote in message
> > news:xxxxx@windbg:
> >
> >> Don’t think you need to code the breakpoint. WINDBG is quite
> >> capable as
> user-mode debugger. Below is debugger spew when debug the “Hello
> World” app, it sets a breakpoint at the start of wmain(), hits the
> breakpoints, then continues execution.
> >>
> >> Microsoft (R) Windows Debugger Version 6.12.0002.633 X86 Copyright
> >> (c) Microsoft Corporation. All rights reserved.
> >>
> >> CommandLine: \dbg\test\Simple\objfre\i386\simple.exe
> >> Symbol search path is:
> >> srvhttp://msdl.microsoft.com/download/symbols
> >> Executable search path is:
> >> ModLoad: 00d00000 00d05000 simple.exe
> >> ModLoad: 76fc0000 77140000 ntdll.dll
> >> ModLoad: 76810000 76910000 E:\Windows\syswow64\kernel32.dll
> >> ModLoad: 763f0000 76436000 E:\Windows\syswow64\KERNELBASE.dll
> >> ModLoad: 754a0000 7554c000 E:\Windows\syswow64\msvcrt.dll
> >> (82c.1358): Break instruction exception - code 80000003 (first
> >> chance)
> >> eax=00000000 ebx=00000000 ecx=9ea30000 edx=0020df38 esi=fffffffe
> edi=76fe3b90
> >> eip=77060b2d esp=000cf3a4 ebp=000cf3d0 iopl=0 nv up ei pl zr na pe
> >> nc
> >> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
> >> ntdll!LdrpDoDebuggerBreak+0x2c:
> >> 77060b2d cc int 3
> >>
> >> 0:000> .reload /f
> >> Reloading current modules
> >> …
> >>
> >> 0:000> k
> >> ChildEBP RetAddr
> >> 000cf3d0 770412e9 ntdll!LdrpDoDebuggerBreak+0x2c
> >> 000cf548 7701209f ntdll!LdrpInitializeProcess+0x132f
> >> 000cf598 76ff9d99 ntdll!_LdrpInitialize+0x78
> >> 000cf5a8 00000000 ntdll!LdrInitializeThunk+0x10
> >>
> >> 0:000> x simple!wmain
> >> 006311f0 simple!wmain (int, unsigned short **)
> >> 006314a0 simple!wmainCRTStartup (void)
> >>
> >> 0:000> bp simple!wmain
> >>
> >> 0:000> g
> >> Breakpoint 0 hit
> >> eax=000d0000 ebx=00000000 ecx=00d03674 edx=00000000 esi=00000001
> edi=00000000
> >> eip=00d011f0 esp=000cf7e4 ebp=000cf820 iopl=0 nv up ei pl zr na pe
> >> nc
> >> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
> >> simple!wmain:
> >> 00d011f0 8bff mov edi,edi
> >>
> >> 0:000> k
> >> ChildEBP RetAddr
> >> 000cf7e0 00d01433 simple!wmain
> >> 000cf820 76823677 simple! wmainCRTStartup+0x100 000cf82c 76ff9e12
> >> kernel32!BaseThreadInitThunk+0xe 000cf86c 76ff9de5
> >> ntdll! RtlUserThreadStart+0x70
> >> 000cf884 00000000 ntdll!_RtlUserThreadStart+0x1b
> >>
> >> 0:000> g
> >> Hello world
> >> eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=770c2100
> edi=770c20c0
> >> eip=76fdfc52 esp=000cf760 ebp=000cf77c iopl=0 nv up ei pl nz na po
> >> nc
> >> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
> >> ntdll!ZwTerminateProcess+0x12:
> >> 76fdfc52 83c404 add esp,4
> >>
> >> 0:000> k
> >> ChildEBP RetAddr
> >> 000cf760 7701a2d4 ntdll!ZwTerminateProcess+0x12 000cf77c 76827362
> >> ntdll!RtlExitUserProcess+0x85
> >> 000cf790 754b36dc kernel32!ExitProcessStub+0x12 000cf79c 754b3371
> >> msvcrt! crtExitProcess+0x17
> >> 000cf7d4 754b36bb msvcrt!doexit+0xac
> >> 000cf7e8 00d0144a msvcrt!exit+0x11
> >> 000cf820 76823677 simple! wmainCRTStartup+0x117 000cf82c 76ff9e12
> >> kernel32!BaseThreadInitThunk+0xe 000cf86c 76ff9de5
> >> ntdll!__RtlUserThreadStart+0x70
> >> 000cf884 00000000 ntdll!_RtlUserThreadStart+0x1b
> >>
> >> 0:000> q
> >> quit:
> >>
> >> -----Original Message-----
> >> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of Don Burn
> >> Sent: Wednesday, September 08, 2010 03:26 PM
> >> To: Kernel Debugging Interest List
> >> Subject: Re:[windbg] Using WinDbg on application-level code
> >>
> >> Joe,
> >>
> >> I you are using the kernel mode Windbg setup to debug a user mode
> program, you either need a hardcoded breakpoint in the program, or
> there is a magic command in Windbg which I can never remember.
> Personally, I just code the breakpoint.
> >>
> >>
> >> Don Burn (MVP, Windows DKD)
> >> Windows Filesystem and Driver Consulting
> >> Website: http://www.windrvr.com
> >> Blog: http://msmvps.com/blogs/WinDrvr
> >>
> >>
> >>
> >>
> >> “Joseph M. Newcomer” wrote in message
> >> news:xxxxx@windbg:
> >>
> >> > As a piece of curiosity, and to allow me to demonstrate
> >> > something, I was investigating the use of WinDbg in debugging
> >> > user-level applications. I created a truly-trivial hello-world
> >> > equivalent, started WinDbg, did an “Open Executable”, and ran it.
> >> > Sure enough, it popped up a console window and the output came out.
> >> >
> >> > So I tried to set a breakpoint. It didn’t work. Odd. So I started
> >> > single-stepping, and found myself in code I didn’t recognize as
> >> > belonging to my program. Odd. In fact, I found myself in
> >> > NTDLL.DLL,
> without symbols.
> >> > Odder. So I set up a pointer to the msdl symbols server. Still no
> >> > luck; it appears either the symbol server doesn’t support
> >> > ntdll.dll in user mode or I did something else wrong (but I
> >> > copied-and-pasted the line from a version of WinDbg I use for
> >> > analyzing crash dumps, where it does work, at least for the kernel).
.reload did nothing.
> >> > Ultimately, it looked like it was executing code that would
> >> > cause my program to run, rather than executing my program’s code.
Odder still.
> >> >
> >> > Did I miss something essential about using WinDbg for applications?
> >> > (This is entirely possible, as I normally only use it for driver
> >> > work, where I have only the usual and familiar problems with it).
> >> > joe
> >>
> >>
> >> —
> >> WINDBG is sponsored by OSR
> >>
> >> 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
> >
> >
> > —
> > WINDBG is sponsored by OSR
> >
> > 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

—
WINDBG is sponsored by OSR

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

—
WINDBG is sponsored by OSR

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

OSR_Community_User · September 8, 2010, 9:35pm

That’s what was weird. I couldn’t find my symbol anywhere.
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Cariddi
Sent: Wednesday, September 08, 2010 9:26 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] RE:Re:Using WinDbg on application-level code

I do this all the time. I just do open executable and I get a breakpoint
somewhere in NTDLL. I then set a breakpoint in my executable and hit go.
I am then in my image and can set whatever other breakpoints I need.

–Mark Cariddi
OSR Open Systems Resources ,Inc.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Joseph M. Newcomer
Sent: Wednesday, September 08, 2010 9:22 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] RE:Re:Using WinDbg on application-level code

The documentation is unclear, as am I, about what this means. If I want to
run a program under WinDbg, what is the magical incantation?
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Wednesday, September 08, 2010 7:40 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] RE:Re:Using WinDbg on application-level code

The “Open Executable” menu item initiates local user mode debugging, not kd.

S

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Wednesday, September 08, 2010 4:16 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] RE:Re:Using WinDbg on application-level code

Martin,

He is directly invoking Windbg to debug the executable. I was asking
Joe if he was doing that or trying to use the kernel debugging and the
invoke the application on the remote machine. I assure you the tricks you
have to use are quite different.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“MARTIN OBRIEN” wrote in message
news:xxxxx@windbg:

> He didn’t - he opened an executive.
>
> On Sep 8, 2010 7:07 PM, “Don Burn” wrote:
> > And the output below is for using Windbg as a user space debugger.
> > If you have it setup for kernel mode debugging this does not work.
> >
> >
> > Don Burn (MVP, Windows DKD)
> > Windows Filesystem and Driver Consulting
> > Website: http://www.windrvr.com
> > Blog: http://msmvps.com/blogs/WinDrvr
> >
> >
> >
> >
> > “Jen-Lung Chiu” wrote in message
> > news:xxxxx@windbg:
> >
> >> Don’t think you need to code the breakpoint. WINDBG is quite
> >> capable as
> user-mode debugger. Below is debugger spew when debug the “Hello
> World” app, it sets a breakpoint at the start of wmain(), hits the
> breakpoints, then continues execution.
> >>
> >> Microsoft (R) Windows Debugger Version 6.12.0002.633 X86 Copyright
> >> (c) Microsoft Corporation. All rights reserved.
> >>
> >> CommandLine: \dbg\test\Simple\objfre\i386\simple.exe
> >> Symbol search path is:
> >> srvhttp://msdl.microsoft.com/download/symbols
> >> Executable search path is:
> >> ModLoad: 00d00000 00d05000 simple.exe
> >> ModLoad: 76fc0000 77140000 ntdll.dll
> >> ModLoad: 76810000 76910000 E:\Windows\syswow64\kernel32.dll
> >> ModLoad: 763f0000 76436000 E:\Windows\syswow64\KERNELBASE.dll
> >> ModLoad: 754a0000 7554c000 E:\Windows\syswow64\msvcrt.dll
> >> (82c.1358): Break instruction exception - code 80000003 (first
> >> chance)
> >> eax=00000000 ebx=00000000 ecx=9ea30000 edx=0020df38 esi=fffffffe
> edi=76fe3b90
> >> eip=77060b2d esp=000cf3a4 ebp=000cf3d0 iopl=0 nv up ei pl zr na pe
> >> nc
> >> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
> >> ntdll!LdrpDoDebuggerBreak+0x2c:
> >> 77060b2d cc int 3
> >>
> >> 0:000> .reload /f
> >> Reloading current modules
> >> …
> >>
> >> 0:000> k
> >> ChildEBP RetAddr
> >> 000cf3d0 770412e9 ntdll!LdrpDoDebuggerBreak+0x2c
> >> 000cf548 7701209f ntdll!LdrpInitializeProcess+0x132f
> >> 000cf598 76ff9d99 ntdll!_LdrpInitialize+0x78
> >> 000cf5a8 00000000 ntdll!LdrInitializeThunk+0x10
> >>
> >> 0:000> x simple!wmain
> >> 006311f0 simple!wmain (int, unsigned short **)
> >> 006314a0 simple!wmainCRTStartup (void)
> >>
> >> 0:000> bp simple!wmain
> >>
> >> 0:000> g
> >> Breakpoint 0 hit
> >> eax=000d0000 ebx=00000000 ecx=00d03674 edx=00000000 esi=00000001
> edi=00000000
> >> eip=00d011f0 esp=000cf7e4 ebp=000cf820 iopl=0 nv up ei pl zr na pe
> >> nc
> >> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
> >> simple!wmain:
> >> 00d011f0 8bff mov edi,edi
> >>
> >> 0:000> k
> >> ChildEBP RetAddr
> >> 000cf7e0 00d01433 simple!wmain
> >> 000cf820 76823677 simple! wmainCRTStartup+0x100 000cf82c 76ff9e12
> >> kernel32!BaseThreadInitThunk+0xe 000cf86c 76ff9de5
> >> ntdll! RtlUserThreadStart+0x70
> >> 000cf884 00000000 ntdll!_RtlUserThreadStart+0x1b
> >>
> >> 0:000> g
> >> Hello world
> >> eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=770c2100
> edi=770c20c0
> >> eip=76fdfc52 esp=000cf760 ebp=000cf77c iopl=0 nv up ei pl nz na po
> >> nc
> >> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
> >> ntdll!ZwTerminateProcess+0x12:
> >> 76fdfc52 83c404 add esp,4
> >>
> >> 0:000> k
> >> ChildEBP RetAddr
> >> 000cf760 7701a2d4 ntdll!ZwTerminateProcess+0x12 000cf77c 76827362
> >> ntdll!RtlExitUserProcess+0x85
> >> 000cf790 754b36dc kernel32!ExitProcessStub+0x12 000cf79c 754b3371
> >> msvcrt! crtExitProcess+0x17
> >> 000cf7d4 754b36bb msvcrt!doexit+0xac
> >> 000cf7e8 00d0144a msvcrt!exit+0x11
> >> 000cf820 76823677 simple! wmainCRTStartup+0x117 000cf82c 76ff9e12
> >> kernel32!BaseThreadInitThunk+0xe 000cf86c 76ff9de5
> >> ntdll!__RtlUserThreadStart+0x70
> >> 000cf884 00000000 ntdll!_RtlUserThreadStart+0x1b
> >>
> >> 0:000> q
> >> quit:
> >>
> >> -----Original Message-----
> >> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of Don Burn
> >> Sent: Wednesday, September 08, 2010 03:26 PM
> >> To: Kernel Debugging Interest List
> >> Subject: Re:[windbg] Using WinDbg on application-level code
> >>
> >> Joe,
> >>
> >> I you are using the kernel mode Windbg setup to debug a user mode
> program, you either need a hardcoded breakpoint in the program, or
> there is a magic command in Windbg which I can never remember.
> Personally, I just code the breakpoint.
> >>
> >>
> >> Don Burn (MVP, Windows DKD)
> >> Windows Filesystem and Driver Consulting
> >> Website: http://www.windrvr.com
> >> Blog: http://msmvps.com/blogs/WinDrvr
> >>
> >>
> >>
> >>
> >> “Joseph M. Newcomer” wrote in message
> >> news:xxxxx@windbg:
> >>
> >> > As a piece of curiosity, and to allow me to demonstrate
> >> > something, I was investigating the use of WinDbg in debugging
> >> > user-level applications. I created a truly-trivial hello-world
> >> > equivalent, started WinDbg, did an “Open Executable”, and ran it.
> >> > Sure enough, it popped up a console window and the output came out.
> >> >
> >> > So I tried to set a breakpoint. It didn’t work. Odd. So I started
> >> > single-stepping, and found myself in code I didn’t recognize as
> >> > belonging to my program. Odd. In fact, I found myself in
> >> > NTDLL.DLL,
> without symbols.
> >> > Odder. So I set up a pointer to the msdl symbols server. Still no
> >> > luck; it appears either the symbol server doesn’t support
> >> > ntdll.dll in user mode or I did something else wrong (but I
> >> > copied-and-pasted the line from a version of WinDbg I use for
> >> > analyzing crash dumps, where it does work, at least for the kernel).
.reload did nothing.
> >> > Ultimately, it looked like it was executing code that would
> >> > cause my program to run, rather than executing my program’s code.
Odder still.
> >> >
> >> > Did I miss something essential about using WinDbg for applications?
> >> > (This is entirely possible, as I normally only use it for driver
> >> > work, where I have only the usual and familiar problems with it).
> >> > joe
> >>
> >>
> >> —
> >> WINDBG is sponsored by OSR
> >>
> >> 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
> >
> >
> > —
> > WINDBG is sponsored by OSR
> >
> > 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

—
WINDBG is sponsored by OSR

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

—
WINDBG is sponsored by OSR

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

–
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.

—
WINDBG is sponsored by OSR

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

—
WINDBG is sponsored by OSR

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

–
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

mm1 · September 8, 2010, 9:37pm

+1

That’s what I was trying to say. Every time (admittedly not a huge number)
I’ve done this, so long as I had my symbols setup correctly it works,
starting with a breakpoint in NTDLL.

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Cariddi
Sent: Wednesday, September 08, 2010 9:26 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] RE:Re:Using WinDbg on application-level code

I do this all the time. I just do open executable and I get a breakpoint
somewhere in NTDLL. I then set a breakpoint in my executable and hit go.
I am then in my image and can set whatever other breakpoints I need.

–Mark Cariddi
OSR Open Systems Resources ,Inc.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Joseph M. Newcomer
Sent: Wednesday, September 08, 2010 9:22 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] RE:Re:Using WinDbg on application-level code

The documentation is unclear, as am I, about what this means. If I want to
run a program under WinDbg, what is the magical incantation?
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Wednesday, September 08, 2010 7:40 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] RE:Re:Using WinDbg on application-level code

The “Open Executable” menu item initiates local user mode debugging, not kd.

S

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Wednesday, September 08, 2010 4:16 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] RE:Re:Using WinDbg on application-level code

Martin,

He is directly invoking Windbg to debug the executable. I was asking
Joe if he was doing that or trying to use the kernel debugging and the
invoke the application on the remote machine. I assure you the tricks you
have to use are quite different.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“MARTIN OBRIEN” wrote in message
news:xxxxx@windbg:

> He didn’t - he opened an executive.
>
> On Sep 8, 2010 7:07 PM, “Don Burn” wrote:
> > And the output below is for using Windbg as a user space debugger.
> > If you have it setup for kernel mode debugging this does not work.
> >
> >
> > Don Burn (MVP, Windows DKD)
> > Windows Filesystem and Driver Consulting
> > Website: http://www.windrvr.com
> > Blog: http://msmvps.com/blogs/WinDrvr
> >
> >
> >
> >
> > “Jen-Lung Chiu” wrote in message
> > news:xxxxx@windbg:
> >
> >> Don’t think you need to code the breakpoint. WINDBG is quite
> >> capable as
> user-mode debugger. Below is debugger spew when debug the “Hello
> World” app, it sets a breakpoint at the start of wmain(), hits the
> breakpoints, then continues execution.
> >>
> >> Microsoft (R) Windows Debugger Version 6.12.0002.633 X86 Copyright
> >> (c) Microsoft Corporation. All rights reserved.
> >>
> >> CommandLine: \dbg\test\Simple\objfre\i386\simple.exe
> >> Symbol search path is:
> >> srvhttp://msdl.microsoft.com/download/symbols
> >> Executable search path is:
> >> ModLoad: 00d00000 00d05000 simple.exe
> >> ModLoad: 76fc0000 77140000 ntdll.dll
> >> ModLoad: 76810000 76910000 E:\Windows\syswow64\kernel32.dll
> >> ModLoad: 763f0000 76436000 E:\Windows\syswow64\KERNELBASE.dll
> >> ModLoad: 754a0000 7554c000 E:\Windows\syswow64\msvcrt.dll
> >> (82c.1358): Break instruction exception - code 80000003 (first
> >> chance)
> >> eax=00000000 ebx=00000000 ecx=9ea30000 edx=0020df38 esi=fffffffe
> edi=76fe3b90
> >> eip=77060b2d esp=000cf3a4 ebp=000cf3d0 iopl=0 nv up ei pl zr na pe
> >> nc
> >> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
> >> ntdll!LdrpDoDebuggerBreak+0x2c:
> >> 77060b2d cc int 3
> >>
> >> 0:000> .reload /f
> >> Reloading current modules
> >> …
> >>
> >> 0:000> k
> >> ChildEBP RetAddr
> >> 000cf3d0 770412e9 ntdll!LdrpDoDebuggerBreak+0x2c
> >> 000cf548 7701209f ntdll!LdrpInitializeProcess+0x132f
> >> 000cf598 76ff9d99 ntdll!_LdrpInitialize+0x78
> >> 000cf5a8 00000000 ntdll!LdrInitializeThunk+0x10
> >>
> >> 0:000> x simple!wmain
> >> 006311f0 simple!wmain (int, unsigned short **)
> >> 006314a0 simple!wmainCRTStartup (void)
> >>
> >> 0:000> bp simple!wmain
> >>
> >> 0:000> g
> >> Breakpoint 0 hit
> >> eax=000d0000 ebx=00000000 ecx=00d03674 edx=00000000 esi=00000001
> edi=00000000
> >> eip=00d011f0 esp=000cf7e4 ebp=000cf820 iopl=0 nv up ei pl zr na pe
> >> nc
> >> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
> >> simple!wmain:
> >> 00d011f0 8bff mov edi,edi
> >>
> >> 0:000> k
> >> ChildEBP RetAddr
> >> 000cf7e0 00d01433 simple!wmain
> >> 000cf820 76823677 simple! wmainCRTStartup+0x100 000cf82c 76ff9e12
> >> kernel32!BaseThreadInitThunk+0xe 000cf86c 76ff9de5
> >> ntdll! RtlUserThreadStart+0x70
> >> 000cf884 00000000 ntdll!_RtlUserThreadStart+0x1b
> >>
> >> 0:000> g
> >> Hello world
> >> eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=770c2100
> edi=770c20c0
> >> eip=76fdfc52 esp=000cf760 ebp=000cf77c iopl=0 nv up ei pl nz na po
> >> nc
> >> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
> >> ntdll!ZwTerminateProcess+0x12:
> >> 76fdfc52 83c404 add esp,4
> >>
> >> 0:000> k
> >> ChildEBP RetAddr
> >> 000cf760 7701a2d4 ntdll!ZwTerminateProcess+0x12 000cf77c 76827362
> >> ntdll!RtlExitUserProcess+0x85
> >> 000cf790 754b36dc kernel32!ExitProcessStub+0x12 000cf79c 754b3371
> >> msvcrt! crtExitProcess+0x17
> >> 000cf7d4 754b36bb msvcrt!doexit+0xac
> >> 000cf7e8 00d0144a msvcrt!exit+0x11
> >> 000cf820 76823677 simple! wmainCRTStartup+0x117 000cf82c 76ff9e12
> >> kernel32!BaseThreadInitThunk+0xe 000cf86c 76ff9de5
> >> ntdll!__RtlUserThreadStart+0x70
> >> 000cf884 00000000 ntdll!_RtlUserThreadStart+0x1b
> >>
> >> 0:000> q
> >> quit:
> >>
> >> -----Original Message-----
> >> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of Don Burn
> >> Sent: Wednesday, September 08, 2010 03:26 PM
> >> To: Kernel Debugging Interest List
> >> Subject: Re:[windbg] Using WinDbg on application-level code
> >>
> >> Joe,
> >>
> >> I you are using the kernel mode Windbg setup to debug a user mode
> program, you either need a hardcoded breakpoint in the program, or
> there is a magic command in Windbg which I can never remember.
> Personally, I just code the breakpoint.
> >>
> >>
> >> Don Burn (MVP, Windows DKD)
> >> Windows Filesystem and Driver Consulting
> >> Website: http://www.windrvr.com
> >> Blog: http://msmvps.com/blogs/WinDrvr
> >>
> >>
> >>
> >>
> >> “Joseph M. Newcomer” wrote in message
> >> news:xxxxx@windbg:
> >>
> >> > As a piece of curiosity, and to allow me to demonstrate
> >> > something, I was investigating the use of WinDbg in debugging
> >> > user-level applications. I created a truly-trivial hello-world
> >> > equivalent, started WinDbg, did an “Open Executable”, and ran it.
> >> > Sure enough, it popped up a console window and the output came out.
> >> >
> >> > So I tried to set a breakpoint. It didn’t work. Odd. So I started
> >> > single-stepping, and found myself in code I didn’t recognize as
> >> > belonging to my program. Odd. In fact, I found myself in
> >> > NTDLL.DLL,
> without symbols.
> >> > Odder. So I set up a pointer to the msdl symbols server. Still no
> >> > luck; it appears either the symbol server doesn’t support
> >> > ntdll.dll in user mode or I did something else wrong (but I
> >> > copied-and-pasted the line from a version of WinDbg I use for
> >> > analyzing crash dumps, where it does work, at least for the kernel).
.reload did nothing.
> >> > Ultimately, it looked like it was executing code that would
> >> > cause my program to run, rather than executing my program’s code.
Odder still.
> >> >
> >> > Did I miss something essential about using WinDbg for applications?
> >> > (This is entirely possible, as I normally only use it for driver
> >> > work, where I have only the usual and familiar problems with it).
> >> > joe
> >>
> >>
> >> —
> >> WINDBG is sponsored by OSR
> >>
> >> 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
> >
> >
> > —
> > WINDBG is sponsored by OSR
> >
> > 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

—
WINDBG is sponsored by OSR

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

—
WINDBG is sponsored by OSR

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

–
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.

—
WINDBG is sponsored by OSR

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

—
WINDBG is sponsored by OSR

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

mm1 · September 8, 2010, 9:40pm

Are you just missing YOUR symbols? If so, I know that this sounds basic,
but is your symbol path set correctly? How about !sym noisy output?

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Joseph M. Newcomer
Sent: Wednesday, September 08, 2010 9:35 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] RE:Re:Using WinDbg on application-level code

That’s what was weird. I couldn’t find my symbol anywhere.
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Cariddi
Sent: Wednesday, September 08, 2010 9:26 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] RE:Re:Using WinDbg on application-level code

I do this all the time. I just do open executable and I get a breakpoint
somewhere in NTDLL. I then set a breakpoint in my executable and hit go.
I am then in my image and can set whatever other breakpoints I need.

–Mark Cariddi
OSR Open Systems Resources ,Inc.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Joseph M. Newcomer
Sent: Wednesday, September 08, 2010 9:22 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] RE:Re:Using WinDbg on application-level code

The documentation is unclear, as am I, about what this means. If I want to
run a program under WinDbg, what is the magical incantation?
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Wednesday, September 08, 2010 7:40 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] RE:Re:Using WinDbg on application-level code

The “Open Executable” menu item initiates local user mode debugging, not kd.

S

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Wednesday, September 08, 2010 4:16 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] RE:Re:Using WinDbg on application-level code

Martin,

He is directly invoking Windbg to debug the executable. I was asking
Joe if he was doing that or trying to use the kernel debugging and the
invoke the application on the remote machine. I assure you the tricks you
have to use are quite different.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“MARTIN OBRIEN” wrote in message
news:xxxxx@windbg:

> He didn’t - he opened an executive.
>
> On Sep 8, 2010 7:07 PM, “Don Burn” wrote:
> > And the output below is for using Windbg as a user space debugger.
> > If you have it setup for kernel mode debugging this does not work.
> >
> >
> > Don Burn (MVP, Windows DKD)
> > Windows Filesystem and Driver Consulting
> > Website: http://www.windrvr.com
> > Blog: http://msmvps.com/blogs/WinDrvr
> >
> >
> >
> >
> > “Jen-Lung Chiu” wrote in message
> > news:xxxxx@windbg:
> >
> >> Don’t think you need to code the breakpoint. WINDBG is quite
> >> capable as
> user-mode debugger. Below is debugger spew when debug the “Hello
> World” app, it sets a breakpoint at the start of wmain(), hits the
> breakpoints, then continues execution.
> >>
> >> Microsoft (R) Windows Debugger Version 6.12.0002.633 X86 Copyright
> >> (c) Microsoft Corporation. All rights reserved.
> >>
> >> CommandLine: \dbg\test\Simple\objfre\i386\simple.exe
> >> Symbol search path is:
> >> srvhttp://msdl.microsoft.com/download/symbols
> >> Executable search path is:
> >> ModLoad: 00d00000 00d05000 simple.exe
> >> ModLoad: 76fc0000 77140000 ntdll.dll
> >> ModLoad: 76810000 76910000 E:\Windows\syswow64\kernel32.dll
> >> ModLoad: 763f0000 76436000 E:\Windows\syswow64\KERNELBASE.dll
> >> ModLoad: 754a0000 7554c000 E:\Windows\syswow64\msvcrt.dll
> >> (82c.1358): Break instruction exception - code 80000003 (first
> >> chance)
> >> eax=00000000 ebx=00000000 ecx=9ea30000 edx=0020df38 esi=fffffffe
> edi=76fe3b90
> >> eip=77060b2d esp=000cf3a4 ebp=000cf3d0 iopl=0 nv up ei pl zr na pe
> >> nc
> >> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
> >> ntdll!LdrpDoDebuggerBreak+0x2c:
> >> 77060b2d cc int 3
> >>
> >> 0:000> .reload /f
> >> Reloading current modules
> >> …
> >>
> >> 0:000> k
> >> ChildEBP RetAddr
> >> 000cf3d0 770412e9 ntdll!LdrpDoDebuggerBreak+0x2c
> >> 000cf548 7701209f ntdll!LdrpInitializeProcess+0x132f
> >> 000cf598 76ff9d99 ntdll!_LdrpInitialize+0x78
> >> 000cf5a8 00000000 ntdll!LdrInitializeThunk+0x10
> >>
> >> 0:000> x simple!wmain
> >> 006311f0 simple!wmain (int, unsigned short **)
> >> 006314a0 simple!wmainCRTStartup (void)
> >>
> >> 0:000> bp simple!wmain
> >>
> >> 0:000> g
> >> Breakpoint 0 hit
> >> eax=000d0000 ebx=00000000 ecx=00d03674 edx=00000000 esi=00000001
> edi=00000000
> >> eip=00d011f0 esp=000cf7e4 ebp=000cf820 iopl=0 nv up ei pl zr na pe
> >> nc
> >> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
> >> simple!wmain:
> >> 00d011f0 8bff mov edi,edi
> >>
> >> 0:000> k
> >> ChildEBP RetAddr
> >> 000cf7e0 00d01433 simple!wmain
> >> 000cf820 76823677 simple! wmainCRTStartup+0x100 000cf82c 76ff9e12
> >> kernel32!BaseThreadInitThunk+0xe 000cf86c 76ff9de5
> >> ntdll! RtlUserThreadStart+0x70
> >> 000cf884 00000000 ntdll!_RtlUserThreadStart+0x1b
> >>
> >> 0:000> g
> >> Hello world
> >> eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=770c2100
> edi=770c20c0
> >> eip=76fdfc52 esp=000cf760 ebp=000cf77c iopl=0 nv up ei pl nz na po
> >> nc
> >> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
> >> ntdll!ZwTerminateProcess+0x12:
> >> 76fdfc52 83c404 add esp,4
> >>
> >> 0:000> k
> >> ChildEBP RetAddr
> >> 000cf760 7701a2d4 ntdll!ZwTerminateProcess+0x12 000cf77c 76827362
> >> ntdll!RtlExitUserProcess+0x85
> >> 000cf790 754b36dc kernel32!ExitProcessStub+0x12 000cf79c 754b3371
> >> msvcrt! crtExitProcess+0x17
> >> 000cf7d4 754b36bb msvcrt!doexit+0xac
> >> 000cf7e8 00d0144a msvcrt!exit+0x11
> >> 000cf820 76823677 simple! wmainCRTStartup+0x117 000cf82c 76ff9e12
> >> kernel32!BaseThreadInitThunk+0xe 000cf86c 76ff9de5
> >> ntdll!__RtlUserThreadStart+0x70
> >> 000cf884 00000000 ntdll!_RtlUserThreadStart+0x1b
> >>
> >> 0:000> q
> >> quit:
> >>
> >> -----Original Message-----
> >> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of Don Burn
> >> Sent: Wednesday, September 08, 2010 03:26 PM
> >> To: Kernel Debugging Interest List
> >> Subject: Re:[windbg] Using WinDbg on application-level code
> >>
> >> Joe,
> >>
> >> I you are using the kernel mode Windbg setup to debug a user mode
> program, you either need a hardcoded breakpoint in the program, or
> there is a magic command in Windbg which I can never remember.
> Personally, I just code the breakpoint.
> >>
> >>
> >> Don Burn (MVP, Windows DKD)
> >> Windows Filesystem and Driver Consulting
> >> Website: http://www.windrvr.com
> >> Blog: http://msmvps.com/blogs/WinDrvr
> >>
> >>
> >>
> >>
> >> “Joseph M. Newcomer” wrote in message
> >> news:xxxxx@windbg:
> >>
> >> > As a piece of curiosity, and to allow me to demonstrate
> >> > something, I was investigating the use of WinDbg in debugging
> >> > user-level applications. I created a truly-trivial hello-world
> >> > equivalent, started WinDbg, did an “Open Executable”, and ran it.
> >> > Sure enough, it popped up a console window and the output came out.
> >> >
> >> > So I tried to set a breakpoint. It didn’t work. Odd. So I started
> >> > single-stepping, and found myself in code I didn’t recognize as
> >> > belonging to my program. Odd. In fact, I found myself in
> >> > NTDLL.DLL,
> without symbols.
> >> > Odder. So I set up a pointer to the msdl symbols server. Still no
> >> > luck; it appears either the symbol server doesn’t support
> >> > ntdll.dll in user mode or I did something else wrong (but I
> >> > copied-and-pasted the line from a version of WinDbg I use for
> >> > analyzing crash dumps, where it does work, at least for the kernel).
.reload did nothing.
> >> > Ultimately, it looked like it was executing code that would
> >> > cause my program to run, rather than executing my program’s code.
Odder still.
> >> >
> >> > Did I miss something essential about using WinDbg for applications?
> >> > (This is entirely possible, as I normally only use it for driver
> >> > work, where I have only the usual and familiar problems with it).
> >> > joe
> >>
> >>
> >> —
> >> WINDBG is sponsored by OSR
> >>
> >> 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
> >
> >
> > —
> > WINDBG is sponsored by OSR
> >
> > 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

—
WINDBG is sponsored by OSR

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

—
WINDBG is sponsored by OSR

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

–
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.

—
WINDBG is sponsored by OSR

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

—
WINDBG is sponsored by OSR

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

–
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.

—
WINDBG is sponsored by OSR

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