I got this message when I was trying to connect the host to target via 1394, and tried several times, but still failed. I am using windows XP sp2 on both computer, and windbg is the newest one downloaded from the microsoft. The target setting is:
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=“Debugging with 1394” /fastdetect /debug /debugport=1394 /channel=10
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=“Microsoft Windows XP Professional” /fastdetect
and the target 1394 controller is disabled.
On the host side, the host setting is
set _NT_DEBUG_BUS=1394
set _NT_DEBUG_1394_CHANNEL=10
then try kd.exe -v, the message on the cmd windows is
using 1394 for debugging
opened \.\DBG1394_INSTANCE10
waiting to reconnect…
I also tried channel 44, but still failed.
Thanks in advance for your help.
Do you have the 1394 controller disabled on the target? Also, you might
try forcing an early break with /break.
mm
>> xxxxx@gmail.com 2007-02-01 14:44 >>>
I got this message when I was trying to connect the host to target via
1394, and tried several times, but still failed. I am using windows XP
sp2 on both computer, and windbg is the newest one downloaded from the
microsoft. The target setting is:
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=“Debugging with 1394”
/fastdetect /debug /debugport=1394 /channel=10
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=“Microsoft Windows XP
Professional” /fastdetect
and the target 1394 controller is disabled.
On the host side, the host setting is
set _NT_DEBUG_BUS=1394
set _NT_DEBUG_1394_CHANNEL=10
then try kd.exe -v, the message on the cmd windows is
using 1394 for debugging
opened \.\DBG1394_INSTANCE10
waiting to reconnect…
I also tried channel 44, but still failed.
Thanks in advance for your help.
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
thank you very much for your reply. I tried using /break after kd command, and got lots of information. It looks that I did not set the symbol path. But, after reset the symbol path, it still did not work, also my target computer is out of control. I am new to windbg, did I miss some settings? Thanks for your help.
WinDbg takes a little getting used to. Once you do, however, it works
quite reliably and well, in my opinion. At the moment, you’ve got my a
little confused. I’m not sure what you mean by “target computer is out
of control,” and the “it still did not work.” To begin, reboot, and at
first break, tpye the following commands:
.reload -f -n srv*LOCAL*http://msdl.microsoft.com/download/symbols
lml
Where LOCAL is the path of your local symbol cache (i. e. - c:\temp,
c:\symbols, et. c.). This will take a few minutes, but what you should
see is a list of modules and symbols with a “(pdb symbols)” appearing on
most of lines.
If you do not get this, please post the commands and the results. If
you do, try whatever was giving you trouble before and post the
results.
mm
>> xxxxx@gmail.com 2007-02-01 17:30 >>>
thank you very much for your reply. I tried using /break after kd
command, and got lots of information. It looks that I did not set the
symbol path. But, after reset the symbol path, it still did not work,
also my target computer is out of control. I am new to windbg, did I
miss some settings? Thanks for your help.
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Thank you very much for your information. When I used “break”, the target computer was dead, I could not move mouse. On the host computer, there were some messages saying
ERROR: Symbol file could not be found. Defaulted to export symbols for ntoskrnl.exe -
windows XP kernel version …
…
You are seeing this message because you pressed either
CTRL+C (if you run kd.exe ) or
CTRL+BREAK (if you run windbg),
on your debugger machine’s keyboard.
This is not a bug or a system crash
if you did not intend to break into the debuggfer, press the “g” key, then press the “enger” key now.
…
BTW, I found on my target computer the 1394 controller was disabled, but as I enabled it, a yellow warning sign “!” was showing beside the item. I do not know if this is the problem. When I started the target computer not in debug mode, there is no that yellow warning after enable/disable the 1394 controller.
Thanks for your help.
Yong
This means that you successfully broke into the target machine with the debugger, and the debugger was waiting for you to decide what to do from there. You cannot use the target computer when the kernel debugger has broken into it.
So it sounds like everything was working for you at that point (although you will need to get proper symbols to do much that is useful).
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Friday, February 02, 2007 10:46 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] debuggee not connected
Thank you very much for your information. When I used “break”, the target computer was dead, I could not move mouse. On the host computer, there were some messages saying
ERROR: Symbol file could not be found. Defaulted to export symbols for ntoskrnl.exe -
windows XP kernel version …
…
You are seeing this message because you pressed either
CTRL+C (if you run kd.exe ) or
CTRL+BREAK (if you run windbg),
on your debugger machine’s keyboard.
This is not a bug or a system crash
if you did not intend to break into the debuggfer, press the “g” key, then press the “enger” key now.
…
BTW, I found on my target computer the 1394 controller was disabled, but as I enabled it, a yellow warning sign “!” was showing beside the item. I do not know if this is the problem. When I started the target computer not in debug mode, there is no that yellow warning after enable/disable the 1394 controller.
Thanks for your help.
Yong
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Oh, it is exciting to hear those two computers are connected. One more question, how to set the symbol path. I downloaded symbols from microsoft and installed in my host computer, but I still got the message when I tried kd -v command.
using 1394 for debugging
opened \.\DBG1394_INSTANCE10
waiting to reconnect…
Thank you very much.
Yong
>>So it sounds like everything was working for you at that point (although
>you will need to get proper symbols to do much that is useful).
The simplest way to configure your symbol path to point to Microsoft’s
public symbol store is the .symfix command.
.symfix+c:\symstore
.reload
Microsoft is pretty good about keeping the store current too.
Ron
Laugh, share and connect with Windows Live Messenger
http://clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?href=http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=hmtagline
Thanks again and I should bother you again. I am new to kernel debugging, so after I tried command .symfix and .reload, what is the next step? I went through the procedure again, but still get the message:
using 1394 for debugging
opened \.\DBG1394_INSTANCE10
waiting to reconnect…
My prucedure is
in cmd window, type
set _NT_DEBUG_BUS=1394
set _NT_DEBUG_1394_CHANNEL=10
then type command
kd.exe -v
Thanks
I don’t believe you will see anything more than that until you either reboot the target (connecting the debugger at startup), or do as some of the spew on your earlier post suggested:
>You are seeing this message because you pressed either
>CTRL+C (if you run kd.exe ) or
On WindBg, if that doesn’t work, then I go to the menus and ask it to resynch the connection, but I don’t know how to do that with kd (hardly ever use it anymore). Probably a command line switch, which would be documented in the reference.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Friday, February 02, 2007 11:36 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] debuggee not connected
Thanks again and I should bother you again. I am new to kernel debugging, so after I tried command .symfix and .reload, what is the next step? I went through the procedure again, but still get the message:
using 1394 for debugging
opened \.\DBG1394_INSTANCE10
waiting to reconnect…
My prucedure is
in cmd window, type
set _NT_DEBUG_BUS=1394
set _NT_DEBUG_1394_CHANNEL=10
then type command
kd.exe -v
Thanks
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
I looked it up- Ctrl-R or [if that doesn’t work for you] .restart. It does say this doesn’t always work with 1394, but I can’t help you there. Never touch the stuff- serial’s just fine by me.
I really thank you guys’ helps. The ‘problem’ is that I do not have patience to wait for the connection. It really take time for the two computer to get connected. Now the two computers are connecting, and get lots of message such as ModLoad:…
thank you very much!!!
Yong
While 1394 seems like a good idea, many of us here have concluded that it is not always reliable and that a simple serial port connection is good enough for most debugging operations.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-277275-
xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Friday, February 02, 2007 3:10 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] debuggee not connected
I really thank you guys’ helps. The ‘problem’ is that I do not have
patience to wait for the connection. It really take time for the two
computer to get connected. Now the two computers are connecting, and
get lots of message such as ModLoad:…
thank you very much!!!
Yong
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>While 1394 seems like a good idea, many of us here have concluded that it
is not always reliable and that a simple serial port connection is good
enough for most
debugging operations.
I agree. However, if you’re planning to do a lot of stepping into/over
instructions, you’ll notice the delay.
Ron
Invite your Hotmail contacts to join your friends list with Windows Live
Spaces
http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us
And the process of creating dump files ranges from tedious to a totally
impractical, if this is your thing.
mm
>> xxxxx@hotmail.com 2007-02-02 17:08 >>>
While 1394 seems like a good idea, many of us here have concluded that
it
is not always reliable and that a simple serial port connection is
good
enough for most
debugging operations.
I agree. However, if you’re planning to do a lot of stepping into/over
instructions, you’ll notice the delay.
Ron
Invite your Hotmail contacts to join your friends list with Windows
Live
Spaces
http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
I have noticed that the reliability of my 1394 debugger is much better
since I put a powered 1394 hub in between my machines instead of relying
on the built-in hubs. Even though I tend to only have one test machine
these days.
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Friday, February 02, 2007 2:48 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] debuggee not connected
And the process of creating dump files ranges from tedious to a totally
impractical, if this is your thing.
mm
>> xxxxx@hotmail.com 2007-02-02 17:08 >>>
While 1394 seems like a good idea, many of us here have concluded that
it
is not always reliable and that a simple serial port connection is
good
enough for most
debugging operations.
I agree. However, if you’re planning to do a lot of stepping into/over
instructions, you’ll notice the delay.
Ron
Invite your Hotmail contacts to join your friends list with Windows
Live
Spaces
http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http:/
/spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mk
t=en-us
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>And the process of creating dump files ranges from tedious to a totally
impractical, if this is your thing.
Yeah, don’t try the .dump command over a serial port. The .crash command is
a better option, especially for perpetual hang or deadlock scenarios.
Ron
Search for grocery stores. Find gratitude. Turn a simple search into
something more.
http://click4thecause.live.com/search/charity/default.aspx?source=hmemtagline_gratitude&FORM=WLMTAG
Not if you don’t want to crash.
>> xxxxx@hotmail.com 2007-02-02 18:16 >>>
And the process of creating dump files ranges from tedious to a
totally
impractical, if this is your thing.
Yeah, don’t try the .dump command over a serial port. The .crash
command is
a better option, especially for perpetual hang or deadlock scenarios.
Ron
Search for grocery stores. Find gratitude. Turn a simple search into
something more.
http://click4thecause.live.com/search/charity/default.aspx?source=hmemtagline_gratitude&FORM=WLMTAG
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Hi Peter - I’m intrigued by your comment :
“I have noticed that the reliability of my 1394 debugger is much better
since I put a powered 1394 hub in between my machines instead of relying
on the built-in hubs. Even though I tend to only have one test machine
these days.”
I’ve just started 1394 kernel debugging myself and just got it working today. When you say powered hub, do you mean the $20 - $40 hubs that have a couple of USB ports and a couple of 1394 ports?
I appreciate the comments of those who say serial works fine. I felt somewhat forced to 1394 because my test machine motherboard didn’t include an on-board serial port so I purchased a serial card. I could never it get it to connect. I think it’s because the driver for that serial card doesn’t load soon enough for the debugger to attach, but I’m not sure. After several days of trying to get the serial debug to work, I moved to 1394 and making some progress.
Does anyone here know if/how I can get my serial card to work in kernel debug?
Thanks!