Symbols and source show up everywhere except in source window

[Guillaume]

I am not able to show the source window in my debugging setup, but
source and line numbers show up everywhere else. I wonder what's
wrong : my setup or my expectations?

For my tests, I run 02sample.exe, with private symbols and source
taken from the website of "Advanced Windows Debugging" -- great book
BTW. This is just to keep things simple, as I am really looking to
debug an authentication package.

It runs on a Server 2003 (free, not checked) virtual machine,
debugging to COM1, redirected to a named pipe. I run ntsd -d -G
02sample.exe on the target and windbg -k com:pipe,port=\\.\pipe\vpc1
on the client.

I entered the .lines -e command so that line numbers show up in the
stack trace.

I can set breakpoints, trace by source line, symbols and line numbers
show up everywhere, I just can't get a source window to show up.
Symbol and source path are relative to ntsd. I also have the symbols
and sources locally.

From what I read, a source window should display automatically when a
breakpoint is hit. What am I missing ?

Here is a sample output of a debuggin session :

Microsoft (R) Windows Debugger Version 6.11.0001.402 X86
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine: \source-and-symbols\src\downloaded\awd-book\bin
\WinXP.x86.fre\02sample.exe
Symbol search path is: c:\source-and-symbols\src\downloaded\awd-book
\symstore.pri
Executable search path is:
ModLoad: 01000000 01005000 02sample.exe
ModLoad: 7c800000 7c8c0000 ntdll.dll
ModLoad: 77e40000 77f42000 C:\WINDOWS\system32\kernel32.dll
ModLoad: 77ba0000 77bfa000 C:\WINDOWS\system32\msvcrt.dll
(954.980): Break instruction exception - code 80000003 (first chance)
eax=77c00000 ebx=7ffdb000 ecx=00000003 edx=00000008 esi=7c8877f4
edi=00081f38
eip=7c81a3e1 esp=0006fb70 ebp=0006fcb4 iopl=0 nv up ei pl nz
na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000202
*** ERROR: Symbol file could not be found. Defaulted to export
symbols for ntdll.dll -
ntdll!DbgBreakPoint:
7c81a3e1 cc int 3
0:000> .lines -e
.lines -e
Line number information will be loaded
0:000> bu 02sample!OutputDebug
bu 02sample!OutputDebug
0:000> bl
bl
0 e 010019fe 0001 (0001) 0:**** 02sample!OutputDebug
0:000> g
g
Breakpoint 0 hit
eax=010019fe ebx=010014e8 ecx=00000065 edx=ffffffff esi=010030b0
edi=77bd31ca
eip=010019fe esp=0006ff5c ebp=0006ff70 iopl=0 nv up ei pl nz
na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000202
02sample!OutputDebug:
010019fe 684c150001 push offset 02sample!`string' (0100154c)
0:000> k
k
ChildEBP RetAddr
0006ff58 010016fb 02sample!OutputDebug [c:\awd\chapter2\sample.cpp @
200]
0006ff70 01001a2f 02sample!AppInfo::Loop+0x76 [c:\awd\common\menu.h @
47]
0006ff7c 01001c5c 02sample!wmain+0x15 [c:\awd\chapter2\sample.cpp @
228]
*** ERROR: Symbol file could not be found. Defaulted to export
symbols for C:\WINDOWS\system32\kernel32.dll -
0006ffc0 77e6f23b 02sample!__wmainCRTStartup+0x102 [d:\vistartm\base
\crts\crtw32\dllstuff\crtexe.c @ 711]
WARNING: Stack unwind information not available. Following frames may
be wrong.
0006fff0 00000000 kernel32!ProcessIdToSessionId+0x209
0:000> lsc
lsc
No current source file
0:000> lsa 02sample!OutputDebug
lsa 02sample!OutputDebug
196: {
197: }
198: }
199: void OutputDebug()
> 200: {
201: OutputDebugStringA("Application ");
202: OutputDebugStringW(L" running\n");
203: }
204:
205:
0:000> lsc
lsc
Current: c:\awd\chapter2\sample.cpp(206)
0:000> windbg> .open sample.cpp
Unable to find 'sample.cpp'

[Scott Noone]

Is your source located in c:\awd? If not try setting your source path to
where you have the source located.

-scott

--
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

Looking forward to seeing you at the next OSR Kernel Debugging Class April
6, 2009 in Portland, OR!

"Guillaume" <ixe...@gmail.com> wrote in message
news:7e839ddc-9326-4668...@f33g2000vbf.googlegroups.com...

[Guillaume]

Yes, it is. And it is readable (see dir and findstr below). Again, to
be on the safe side, I made sure the file was at the same place on the
target and the client.

$ dir c:\awd\chapter2\sample.cpp && findstr /c:OutputDebug /n c:\awd
\chapter2\sample.cpp
Volume in drive C has no label.
Volume Serial Number is B0A2-ABC7

Directory of c:\awd\chapter2

10/26/2007 03:04 PM 5,312 sample.cpp
1 File(s) 5,312 bytes
0 Dir(s) 16,673,792,000 bytes free

199:void OutputDebug()

201: OutputDebugStringA("Application ");
202: OutputDebugStringW(L" running\n");

220:{L'e',L"To call OutputDebugString",OutputDebug},

--
Guillaume

On Mar 10, 3:47 pm, "Scott Noone" <sno...@osr.com> wrote:
> Is your source located in c:\awd? If not try setting your source path to
> where you have the source located.
>
> -scott
>
> --
> Scott Noone
> Consulting Associate

> OSR Open Systems Resources, Inc.http://www.osronline.com

[pat styles [microsoft]]

Hello Guillaume.

It would probably valuable for you to use the .srcpath command to display
the source path in use by the debugger. However if the file is in the same
location as it was at compile time, I would expect it to open anyway. Have
you tried using the .srcnoisy command to get detailed spew of the
debuggers's attempts to load source? That should be enlightening.

.pat styles [microsoft]

"Guillaume" <ixe...@gmail.com> wrote in message
news:7e839ddc-9326-4668...@f33g2000vbf.googlegroups.com...

[Guillaume]

I messed up my VM playing with gflags - maybe something else... Now it
won't boot anymore :(

I saved a few debug sessions output, .srcpath shows c:\awd\chapter2,
but none of them show .srcnoisy enabled. My bad.

I will fix my VM. I understand from your answer that a source window
should display in remote debugging, just like it does when debugging
locally. Am I on the right track putting sources and symbols relative
to where ntsd is running, not windbg, even if windbg will be actually
displaying those source files ?

Thanks for your help,

--
Guillaume

On Mar 11, 11:40 am, "pat styles [microsoft]"

[pat styles [microsoft]]

Hello Guillaume.

No. You want symbols to be available to where the target debugger (ntsd) is
running and source available on the host (windbg).

.pat styles [microsoft]

"Guillaume" <ixe...@gmail.com> wrote in message

news:1f5aa868-210e-49d6...@k19g2000prh.googlegroups.com...

[Guillaume]

I'm back with a fresh install of Server2003 in a virtual machine. To
be on safe side, I removed all windbg theme information from the
registry. Sources and symbols are in the same path on both the target
and the host. The exact same name as in the PDB. If I debug the
application locally, at either end, windbg shows the source as soon as
a breakpoint is hit. I can single step from the source window, hit F9
to set new breakpoints, etc.

But if I run ntsd -d on the target and windbg -k on the other, source
still doesn't show up (see full command line below). I tried .srcnoisy
3, but not much is shown. The only trace I found was when I do this :

0:000> lsa 02sample!OutputDebug
lsa 02sample!OutputDebug

DBGENG: Find 'c:\awd\chapter2\sample.cpp'
DBGENG: Scan paths for partial path match:
DBGENG: prefix 'c:\awd\chapter2'
DBGENG: suffix 'sample.cpp'
DBGENG: match 'c:\awd\chapter2' against 'c:\awd\chapter2': -1
(match 'c:\awd\chapter2')
DBGENG: check 'c:\awd\chapter2\sample.cpp'
DBGENG: found file 'c:\awd\chapter2\sample.cpp'

196: {
197: }
198: }
199: void OutputDebug()
> 200: {
201: OutputDebugStringA("Application ");
202: OutputDebugStringW(L" running\n");
203: }
204:
205:

Source is found, why isn't it shown ? After that, I can .open
sample.cpp, but trying to set a breakpoint gives me "Debuggee must be
stopped before breakpoints can be modified.", even if I am already
stopped at a DebugBreak.

Here are the remote and host command lines (cwd is debuggin tools for
windows) :
ntsd.exe -d -lines -G -v -y C:\awd\symstore.pri -srcpath c:\awd
\chapter2 C:\awd\WinXP.x86.fre\02sample.exe
windbg.exe -G -v -y C:\awd\symstore.pri -srcpath c:\awd
\chapter2 -k com:pipe,port=\\.\pipe\vpc1,reconnect

Thanks for your help,

On Mar 12, 1:23 pm, "pat styles [microsoft]"

[Guillaume]

I had given up on source level debugging, using windbg -k with dv and
lsa .

But I just made it work by using breakin.exe and *not* using ntsd -d
on the target at all.

In other words,
1. I enable debugging with bootcfg on the target.
2. I make symbols available on the target (local copy)
3. On the host, I start windbg -k, with sympath relative to the target
and srcpath relative to the host
4. On the target, I launch breakin.exe 316 (that's Winlogon.exe)
5. On the host windbg kd> prompt, I can set breakpoints with symbol
names
6. The source window appears when the breakpoint is hit. Yé !

That confirms my source and symbol setup is ok. But this technique
will not let me debug a function called early in the boot process,
like LsaApInitializePackage. I have other problems with ntsd -d that
deserve their own post...

--
Guillaume

[JasonM]

I recently opened a support incident with Microsoft about basically the same
issue. I could get source code if I was debugging locally, however remote
debugging did not work with Source Code instrumented PDBS. This was true for
both WinDBG and Visual Studio.

In the end, it turned out to be a bug on Microsoft's side. As of the close
of my case they were not planning to hotfix this issue, however a fix is
tentatively expected to be included in the next release of visual studio
(2010). They couldn't give me their internal bug ID, but it is included in
case ID SRX090224600301 for any MS people who want to look it up.

[pat styles [microsoft]]

Hello Jason.

VS and WinDbg do not use common code to handle source access through remote
debugging setups. That is unless you are describing the Source Server
technology. If a bug was found in there, I would think that I would have
heard of it.

Would you mind sending whatever details you have on this to my email
address? I just want to do some due diligence.

thanks,
.pat styles [microsoft]

"JasonM" <Jas...@discussions.microsoft.com> wrote in message
news:B333D9E0-22AB-4BED...@microsoft.com...