RE: WINDBG 1394 FIREWIRE DEBUGGING PROBLEM

NTDEV
1

42? I thought that was the answer to life, the universe and everything,
the result of 6 times 9 in base 13.

Seriously … have you tried a lower channel number, say, between 1 and
16?

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of tumtum@o2.pl
Sent: Thursday, June 01, 2006 7:55 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] WINDBG 1394 FIREWIRE DEBUGGING PROBLEM

Hi guys!

I’m currently having problems with remote debugging via 1394 (firewire
port).
I’ve read all Microsoft documents (including DW04001_WINHEC2004.ppt - 1394
kernel debugging
presentation) and i’ve googled for the same problem i’m having right now,
and i haven’t
found any solution so i have decided to ask for help here.

I have added following options to the host boot.ini:
“/debugport=1394 /channel=42”

machine starts normally in the debug mode, the problem is i can’t connect
to it
from other machine, here’s the output from the target:

set _NT_SYMBOL_PATH=c:\windows\system32\symbols
set _NT_DEBUG_BUS=1394
set _NT_DEBUG_1394_CHANNEL=42
set _NT_DEBUG_LOG_FILE_OPEN=F:\DEBUG.LOG
windbg -k

windbg outputs:

Using 1394 for debugging
Opened \.\DBG1394_CHANNEL42

Microsoft (R) Windows Kernel Debugger Version 3.0.0020.0
Copyright (c) Microsoft Corporation. All rights reserved.

Waiting to reconnect…

And nothing more happens :frowning:
I tried disabling/enabling the host 1394 adaptor, changing debug channels
with
the same results.

I have also uploaded two screenshots, with host adaptor enabled and
disabled:
(the strange is when i disable the adaptor, the windbg 1394 drivers are
also
not visible…)

HOST MACHINE:

Any ideas whats wrong? Thanks for help!

best regards,
tumtum

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

2

OK, cool. Now break in. As in: Send a manual break. From Windbg, it’s
Ctrl+Break, or press the button that looks like a sheet of paper with a
blue pause icon on it. Or even use the Debug->Break menu item.

You can also start your debugger first, use Ctrl+Alt+K to cycle the
initial breakpoint behavior to “Will request initial breakpoint at next
boot.” or “Will breakin on first symbol load at next boot.”, then start
your target, and it will stop at whichever stage of boot you told it to
break.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of tumtum@o2.pl
Sent: Thursday, June 01, 2006 6:55 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] WINDBG 1394 FIREWIRE DEBUGGING PROBLEM

Hi guys!

I’m currently having problems with remote debugging via 1394 (firewire
port).
I’ve read all Microsoft documents (including DW04001_WINHEC2004.ppt - 1394
kernel debugging
presentation) and i’ve googled for the same problem i’m having right now,
and i haven’t
found any solution so i have decided to ask for help here.

I have added following options to the host boot.ini:
“/debugport=1394 /channel=42”

machine starts normally in the debug mode, the problem is i can’t connect
to it
from other machine, here’s the output from the target:

set _NT_SYMBOL_PATH=c:\windows\system32\symbols
set _NT_DEBUG_BUS=1394
set _NT_DEBUG_1394_CHANNEL=42
set _NT_DEBUG_LOG_FILE_OPEN=F:\DEBUG.LOG
windbg -k

windbg outputs:

Using 1394 for debugging
Opened \.\DBG1394_CHANNEL42

Microsoft (R) Windows Kernel Debugger Version 3.0.0020.0
Copyright (c) Microsoft Corporation. All rights reserved.

Waiting to reconnect…

And nothing more happens :frowning:
I tried disabling/enabling the host 1394 adaptor, changing debug channels
with
the same results.

I have also uploaded two screenshots, with host adaptor enabled and
disabled:
(the strange is when i disable the adaptor, the windbg 1394 drivers are
also
not visible…)

HOST MACHINE:

Any ideas whats wrong? Thanks for help!

best regards,
tumtum

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

3

There’s nothing wrong with 42. That’s definitely not his problem.

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G Little
Sent: Thursday, June 01, 2006 8:14 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WINDBG 1394 FIREWIRE DEBUGGING PROBLEM

42? I thought that was the answer to life, the universe and everything,
the result of 6 times 9 in base 13.

Seriously … have you tried a lower channel number, say, between 1 and
16?

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of tumtum@o2.pl
Sent: Thursday, June 01, 2006 7:55 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] WINDBG 1394 FIREWIRE DEBUGGING PROBLEM

Hi guys!

I’m currently having problems with remote debugging via 1394 (firewire
port).
I’ve read all Microsoft documents (including DW04001_WINHEC2004.ppt - 1394
kernel debugging
presentation) and i’ve googled for the same problem i’m having right now,
and i haven’t
found any solution so i have decided to ask for help here.

I have added following options to the host boot.ini:
“/debugport=1394 /channel=42”

machine starts normally in the debug mode, the problem is i can’t connect
to it
from other machine, here’s the output from the target:

set _NT_SYMBOL_PATH=c:\windows\system32\symbols
set _NT_DEBUG_BUS=1394
set _NT_DEBUG_1394_CHANNEL=42
set _NT_DEBUG_LOG_FILE_OPEN=F:\DEBUG.LOG
windbg -k

windbg outputs:

Using 1394 for debugging
Opened \.\DBG1394_CHANNEL42

Microsoft (R) Windows Kernel Debugger Version 3.0.0020.0
Copyright (c) Microsoft Corporation. All rights reserved.

Waiting to reconnect…

And nothing more happens :frowning:
I tried disabling/enabling the host 1394 adaptor, changing debug channels
with
the same results.

I have also uploaded two screenshots, with host adaptor enabled and
disabled:
(the strange is when i disable the adaptor, the windbg 1394 drivers are
also
not visible…)

HOST MACHINE:

Any ideas whats wrong? Thanks for help!

best regards,
tumtum

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

4

There is also a verbose mode for the debug port connection, whose
command syntax escapes me right now. Perhaps somebody can dig it up.
I’ve had similar problems, as has almost everyone who tries using the
firewire port, as it seems that the 1394 chipsets are not all the same.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Thursday, June 01, 2006 11:03 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WINDBG 1394 FIREWIRE DEBUGGING PROBLEM

There’s nothing wrong with 42. That’s definitely not his problem.

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G Little
Sent: Thursday, June 01, 2006 8:14 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WINDBG 1394 FIREWIRE DEBUGGING PROBLEM

42? I thought that was the answer to life, the universe and everything,
the result of 6 times 9 in base 13.

Seriously … have you tried a lower channel number, say, between 1 and
16?

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of tumtum@o2.pl
Sent: Thursday, June 01, 2006 7:55 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] WINDBG 1394 FIREWIRE DEBUGGING PROBLEM

Hi guys!

I’m currently having problems with remote debugging via 1394 (firewire
port).
I’ve read all Microsoft documents (including DW04001_WINHEC2004.ppt -
1394
kernel debugging
presentation) and i’ve googled for the same problem i’m having right
now,
and i haven’t
found any solution so i have decided to ask for help here.

I have added following options to the host boot.ini:
“/debugport=1394 /channel=42”

machine starts normally in the debug mode, the problem is i can’t
connect
to it
from other machine, here’s the output from the target:

set _NT_SYMBOL_PATH=c:\windows\system32\symbols
set _NT_DEBUG_BUS=1394
set _NT_DEBUG_1394_CHANNEL=42
set _NT_DEBUG_LOG_FILE_OPEN=F:\DEBUG.LOG
windbg -k

windbg outputs:

Using 1394 for debugging
Opened \.\DBG1394_CHANNEL42

Microsoft (R) Windows Kernel Debugger Version 3.0.0020.0
Copyright (c) Microsoft Corporation. All rights reserved.

Waiting to reconnect…

And nothing more happens :frowning:
I tried disabling/enabling the host 1394 adaptor, changing debug
channels
with
the same results.

I have also uploaded two screenshots, with host adaptor enabled and
disabled:
(the strange is when i disable the adaptor, the windbg 1394 drivers are
also
not visible…)

HOST MACHINE:

Any ideas whats wrong? Thanks for help!

best regards,
tumtum

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

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

5

Or, on the target, press Ctl+SysRq

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Philip D Barila
Sent: Thursday, June 01, 2006 10:02 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WINDBG 1394 FIREWIRE DEBUGGING PROBLEM

OK, cool. Now break in. As in: Send a manual break. From Windbg, it’s
Ctrl+Break, or press the button that looks like a sheet of paper with a
blue pause icon on it. Or even use the Debug->Break menu item.

You can also start your debugger first, use Ctrl+Alt+K to cycle the
initial breakpoint behavior to “Will request initial breakpoint at next
boot.” or “Will breakin on first symbol load at next boot.”, then start
your target, and it will stop at whichever stage of boot you told it to
break.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of tumtum@o2.pl
Sent: Thursday, June 01, 2006 6:55 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] WINDBG 1394 FIREWIRE DEBUGGING PROBLEM

Hi guys!

I’m currently having problems with remote debugging via 1394 (firewire
port).
I’ve read all Microsoft documents (including DW04001_WINHEC2004.ppt - 1394
kernel debugging
presentation) and i’ve googled for the same problem i’m having right now,
and i haven’t
found any solution so i have decided to ask for help here.

I have added following options to the host boot.ini:
“/debugport=1394 /channel=42”

machine starts normally in the debug mode, the problem is i can’t connect
to it
from other machine, here’s the output from the target:

set _NT_SYMBOL_PATH=c:\windows\system32\symbols
set _NT_DEBUG_BUS=1394
set _NT_DEBUG_1394_CHANNEL=42
set _NT_DEBUG_LOG_FILE_OPEN=F:\DEBUG.LOG
windbg -k

windbg outputs:

Using 1394 for debugging
Opened \.\DBG1394_CHANNEL42

Microsoft (R) Windows Kernel Debugger Version 3.0.0020.0
Copyright (c) Microsoft Corporation. All rights reserved.

Waiting to reconnect…

And nothing more happens :frowning:
I tried disabling/enabling the host 1394 adaptor, changing debug channels
with
the same results.

I have also uploaded two screenshots, with host adaptor enabled and
disabled:
(the strange is when i disable the adaptor, the windbg 1394 drivers are
also
not visible…)

HOST MACHINE:

Any ideas whats wrong? Thanks for help!

best regards,
tumtum

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

6

> I have added following options to the host boot.ini:

“/debugport=1394 /channel=42”
You did not forget “/debug” also, did you?

Here is a line that works for me (some options are extras):

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=“WxpMc + 1394/62 + ntbtlog”
/noexecute=optin /fastdetect /debug /debugport=1394 /channel=62 /bootlog

Another thing: as Mark Roddy noted, some chipsets just don’t work, peiod.

----- Original Message -----
From: “Roddy, Mark”
To: “Windows System Software Devs Interest List”
Sent: Thursday, June 01, 2006 1:35 PM
Subject: RE: [ntdev] WINDBG 1394 FIREWIRE DEBUGGING PROBLEM

There is also a verbose mode for the debug port connection, whose
command syntax escapes me right now. Perhaps somebody can dig it up.
I’ve had similar problems, as has almost everyone who tries using the
firewire port, as it seems that the 1394 chipsets are not all the same.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Thursday, June 01, 2006 11:03 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WINDBG 1394 FIREWIRE DEBUGGING PROBLEM

There’s nothing wrong with 42. That’s definitely not his problem.

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G Little
Sent: Thursday, June 01, 2006 8:14 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WINDBG 1394 FIREWIRE DEBUGGING PROBLEM

42? I thought that was the answer to life, the universe and everything,
the result of 6 times 9 in base 13.

Seriously … have you tried a lower channel number, say, between 1 and
16?

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of tumtum@o2.pl
Sent: Thursday, June 01, 2006 7:55 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] WINDBG 1394 FIREWIRE DEBUGGING PROBLEM

Hi guys!

I’m currently having problems with remote debugging via 1394 (firewire
port).
I’ve read all Microsoft documents (including DW04001_WINHEC2004.ppt -
1394
kernel debugging
presentation) and i’ve googled for the same problem i’m having right
now,
and i haven’t
found any solution so i have decided to ask for help here.

I have added following options to the host boot.ini:
“/debugport=1394 /channel=42”

machine starts normally in the debug mode, the problem is i can’t
connect
to it
from other machine, here’s the output from the target:

set _NT_SYMBOL_PATH=c:\windows\system32\symbols
set _NT_DEBUG_BUS=1394
set _NT_DEBUG_1394_CHANNEL=42
set _NT_DEBUG_LOG_FILE_OPEN=F:\DEBUG.LOG
windbg -k

windbg outputs:
------------------------------------------------------------
Using 1394 for debugging
Opened \.\DBG1394_CHANNEL42

Microsoft (R) Windows Kernel Debugger Version 3.0.0020.0
Copyright (c) Microsoft Corporation. All rights reserved.

Waiting to reconnect…
------------------------------------------------------------

And nothing more happens :frowning:
I tried disabling/enabling the host 1394 adaptor, changing debug
channels
with
the same results.

I have also uploaded two screenshots, with host adaptor enabled and
disabled:
(the strange is when i disable the adaptor, the windbg 1394 drivers are
also
not visible…)

HOST MACHINE:
- enabled: http://img100.imageshack.us/img100/4813/1934enabled1xn.jpg
- disabled: http://img100.imageshack.us/img100/2386/1934disabled0zy.jpg

Any ideas whats wrong? Thanks for help!

best regards,
tumtum

—
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

—
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

7

“sh_alex” wrote:

> > I have added following options to the host boot.ini:
> > “/debugport=1394 /channel=42”
>
> You did not forget “/debug” also, did you?

Pretty certain that’s already implied by simply specifying /DEBUGPORT.
Or at least I’ve never specified literally “/DEBUG” on any of the
configurations where I’m successfully debugging. For what it’s worth.

Alan Adams

8

tumtum@o2.pl wrote:

Microsoft (R) Windows Kernel Debugger Version 3.0.0020.0
Copyright (c) Microsoft Corporation. All rights reserved.

Run away! Circa 2001 debugger. Debugging over 1394 is “new and
improved” enough that I’m pretty sure you’ll benefit from improvements
and fixes by updating to as current a debugger package as you can.

http://www.microsoft.com/whdc/devtools/debugging/default.mspx

And nothing more happens :frowning: I tried disabling/enabling the
host 1394 adaptor, changing debug channels with the same
results.

A point that is sometimes confusing relates to the “disable 1394”
configuration steps.

To my knowledge the correct action is to disable the 1394 controller
in Device Manager on_the_target_machine, not the machine where
you’re running WinDBG (which seems to be what’s implied by your screen
shots, unless I’m mis-reading them).

On the target machine (the one where you’ve enabled /DEBUGPORT and
such in the BOOT.INI), you should disable the 1394 controller in
Device Manager. (Note this ends up disabling both the 1394
controller, and 1394 network adapter provided by XP.)

On the host machine (the one where you’re running WinDBG), disabling
the 1394 network_adapter provided by XP can improve your ability to
connect. But do not disable the 1394 controller itself.

Alan Adams

9

sh_alex wrote:

> I have added following options to the host boot.ini:
> “/debugport=1394 /channel=42”

You did not forget “/debug” also, did you?

Not necessary. As soon as you mention any of the debug options (like
/debugport), /debug is assumed.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

10

> Or at least I’ve never specified literally “/DEBUG” on any of the

configurations where I’m successfully debugging. For what it’s worth.
Will make a note of it.
Never tried to omit /debug myself (and doc’s never said that it’s possible,
IIRC).
Anyway.

----- Original Message -----
From: “Alan Adams”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Thursday, June 01, 2006 6:18 PM
Subject: Re:[ntdev] WINDBG 1394 FIREWIRE DEBUGGING PROBLEM

> “sh_alex” wrote:
>
>> > I have added following options to the host boot.ini:
>> > “/debugport=1394 /channel=42”
>>
>> You did not forget “/debug” also, did you?
>
> Pretty certain that’s already implied by simply specifying /DEBUGPORT.
> Or at least I’ve never specified literally “/DEBUG” on any of the
> configurations where I’m successfully debugging. For what it’s worth.
>
> Alan Adams
>
> —
> 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

11

> I’ve had similar problems, as has almost everyone who tries using the

firewire port, as it seems that the 1394 chipsets are not all the same.

I’d second what Mark said about 1394 chipsets. It took quite a bit of
hunting to find a 1394 card that worked correctly in a 64-bit PCI-X slot.
The 1394 card sold by OSR would not even physically fit in the slot, as I
believe it’s a 5V only card. On my current debug target system, I’m
currently running an Adaptec 1394 card, although had to manually adjust the
PCI bus speed to 33 Mhz in the BIOS on a modern server motherboard. 32-bit
VIA 1394 chipsets simple would not work. I’d have to ask our system folks
what 1394 card they eventually settled on, but believe some 64-bit PCI card
with a TI chipset was the debugging compatibility winner for systems here.

The day is rapidly approaching that a system might ONLY have PCI-e slots,
and NO PCI(X) slots. It would be really nice if Microsoft could tune up the
internal debug 1394 drivers a bit to work with more 1394 cards. Or possibly
add 1394 debug cards to the hardware compatibility tests. Cards that seem to
work fine with the normal 1394 driver don’t always work with the internal
debugging support.

I’ve found the 1394 card in the debugger system matters too, and have also
had the experience of different cable brands making a difference between
1394 debugging working or not.

On the other hand, 1394 is SO much better than a serial connection, almost
any amount of futzing is worth it. I don’t believe my patience has ever been
long enough to do .dump over a serial link, but over 1394 even a couple
gigabytes dumps in a few minutes. Systems also often only have a single
serial port, which is now consumed by EMS. For me, EMS is pretty much a
requirement, as my target machine is in a rack off in a machine room, and is
often 35 miles away when I’m working from home. Remote power management is
pretty essential too.

  • Jan
12

You’re right Alan, /DEBUG is implied when you specify the transport, 1394
or serial. But, I do note that if you use BOOTCFG to setup your boot.ini
file, you will get the /DEBUG switch.

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of alanadams@dr.com
Sent: Thursday, June 01, 2006 5:18 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WINDBG 1394 FIREWIRE DEBUGGING PROBLEM

“sh_alex” wrote:

> > I have added following options to the host boot.ini:
> > “/debugport=1394 /channel=42”
>
> You did not forget “/debug” also, did you?

Pretty certain that’s already implied by simply specifying /DEBUGPORT.
Or at least I’ve never specified literally “/DEBUG” on any of the
configurations where I’m successfully debugging. For what it’s worth.

Alan Adams

—
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

13

Microsoft has said in the windbg newsgroup that the later versions of windbg
do not require disabling the target, but I still do myself. Use the TI
chipset card on both ends. The Via chipset works most of the time too, but
the others are close to lottery odds when getting it to work.

“Alan Adams” wrote in message news:xxxxx@ntdev…
> tumtum@o2.pl wrote:
>
>> Microsoft (R) Windows Kernel Debugger Version 3.0.0020.0
>> Copyright (c) Microsoft Corporation. All rights reserved.
>
> Run away! Circa 2001 debugger. Debugging over 1394 is “new and
> improved” enough that I’m pretty sure you’ll benefit from improvements
> and fixes by updating to as current a debugger package as you can.
>
> http://www.microsoft.com/whdc/devtools/debugging/default.mspx
>
>> And nothing more happens :frowning: I tried disabling/enabling the
>> host 1394 adaptor, changing debug channels with the same
>> results.
>
> A point that is sometimes confusing relates to the “disable 1394”
> configuration steps.
>
> To my knowledge the correct action is to disable the 1394 controller
> in Device Manager on_the_target_machine, not the machine where
> you’re running WinDBG (which seems to be what’s implied by your screen
> shots, unless I’m mis-reading them).
>
> On the target machine (the one where you’ve enabled /DEBUGPORT and
> such in the BOOT.INI), you should disable the 1394 controller in
> Device Manager. (Note this ends up disabling both the 1394
> controller, and 1394 network adapter provided by XP.)
>
> On the host machine (the one where you’re running WinDBG), disabling
> the 1394 network_adapter provided by XP can improve your ability to
> connect. But do not disable the 1394 controller itself.
>
> Alan Adams
>

14

“David J. Craig” wrote:

> Microsoft has said in the windbg newsgroup that the later versions of windbg
> do not require disabling the target, but I still do myself. Use the TI
> chipset card on both ends. The Via chipset works most of the time too, but
> the others are close to lottery odds when getting it to work.

The problem I get when I don’t disable the 1394 controller on the
target, for what it’s worth, is that WinDBG will tend not to connect
automatically. (Not 100% failure; probably 90% failure.)

I can still connect as soon as I attempt to break in; it’s just not
automatic. After I disable the 1394 controller on the target, then
its automatic as you would expect.

That, plus I notice even with a Vista 5384 x86 target, the 1394
controller is reported as “banged” (not functioning properly) in
Device Manager once debugging is enabled. (Seeing this on XP SP2 x86
targets as well.)

This is with an XP SP2 host with WinDBG 6.6.03.5; TI chipset on host,
VIA on targets.

Alan Adams