1394 Debug problem using WinXP SP3

OSR_Community_User · October 6, 2008, 6:45am

Greetings to all,

I am facing some connectivity issue while using 1394 Firewire for WIN Kernel
debugging.Please guide me if someone has overcome the issue.

I using two laptop machines (both of them Win XP SP3) for debug, following
options already listed as solutions at OSR, are also not working:

Disabling 1394controller on target machine.
Disabling 1394 adapter on host machine.
Un installing WinXP SP2 and reinstalling Win XP with no SP on target
machine.
4 Replacing 1394 Drivers (bus, arp,nic,ohci) on both of machines with SP1
drivers and renaming the driver cache.
Win debug Ctl+Alt+D and Ctl+Alt+R options and reboots.

After all such permutation and combinations , i am still stuck up at
“Wating to re-connect”.

Kindly advise me to solve the issue , please let me know if there is any way
to check the firewire cable. Thanks in advance.

Warm regards,
Pranav

OSR_Community_User · October 6, 2008, 7:01am

You definitely do not want to disable the 1394 controller on the host.
Have you told the debugger to break in? If you haven’t done so, you need to do one the following, or it will just sit there at
‘Waiting to connect’ until you do:

a. press ‘CTRL-BREAK’
b. select’Break’ from the ‘Debug’ menu
c. selecting ‘Cycle Initial break point’ from the ‘Debug’ menu and then reboot the target
d. start windbg with the ‘-d’ command line option
e. start windbg with the ‘-b’ command line option and then reboot the target
f. add ‘/BREAK’ to the boot.ini file of the target, reboot the target and select that

If neither of those solve the problem, then my guess would be that the 1394 controller on the target is not compatible with
WinDbg. This is not an uncommon problem, particularly on laptops. I do not personally know the name of a particular model that I
know to work with laptops, but in general anything based on the TI chipset seems to work, and the ‘hardware’ section of the osr
store might have a model that it sells.

Good luck,

mm

Pranav Sharma wrote:

Greetings to all,

I am facing some connectivity issue while using 1394 Firewire for WIN
Kernel debugging.Please guide me if someone has overcome the issue.

I using two laptop machines (both of them Win XP SP3) for debug,
following options already listed as solutions at OSR, are also not working:

Disabling 1394controller on target machine.

Disabling 1394 adapter on host machine.

Un installing WinXP SP2 and reinstalling Win XP with no SP on target
machine.
4 Replacing 1394 Drivers (bus, arp,nic,ohci) on both of machines with
SP1 drivers and renaming the driver cache.

Win debug Ctl+Alt+D and Ctl+Alt+R options and reboots.

After all such permutation and combinations , i am still stuck up at
“Wating to re-connect”.

Kindly advise me to solve the issue , please let me know if there is any
way to check the firewire cable. Thanks in advance.

Warm regards,
Pranav

OSR_Community_User · October 6, 2008, 7:01am

For further information other settings are as follows:

WinDBG 6.8.0004.0 latest version.
Boot.ini :
multi(0)disk(0)rdisk(0)partition(1)\windows=“Microsoft Windows
XP(1394)”
/fastdetect /debugport=1394 /channel=5
WinDBG command line
“C:\Program Files\Debugging Tools for Windows\windbg.exe” -b -k
1394:channel=5
IEEE 1394 4 pin ports on both of the machines.

Regards,
Pranav

OSR_Community_User · October 6, 2008, 7:26am

You don’t have ‘/DEBUG’ in your boot.ini file. I don’t know whether you will be able to connect with WinDbg without it (perhaps
/debugport implies /debug, but I kind of doubt it), but I would add it just to make sure.

Good luck,

mm

xxxxx@gmail.com wrote:

For further information other settings are as follows:

WinDBG 6.8.0004.0 latest version.

Boot.ini :
multi(0)disk(0)rdisk(0)partition(1)\windows=“Microsoft Windows
XP(1394)”
/fastdetect /debugport=1394 /channel=5

WinDBG command line
“C:\Program Files\Debugging Tools for Windows\windbg.exe” -b -k
1394:channel=5

IEEE 1394 4 pin ports on both of the machines.

Regards,
Pranav

OSR_Community_User · October 6, 2008, 7:57am

Thanks for the hints, i tried them but still the state is same. I am not sure if my wire, ports are in good order.Please suggest any way to test the ports and wire.

Is it necessary to have SP1 only to proceed with debugging?

Thanks in advance…

Regards,
Pranav

OSR_Community_User · October 6, 2008, 8:06am

Is SP1 required for debugging on XP? Most definitely not. Although I’ve never debugged an SP3 machine, I’ve also never debugged a
SP1 machine either, so I can only personally confirm that debugging of SP2 definitely works. I’m not sure where you got the SP1
idea, but I seriously doubt that it’s correct.

I’ve also never used a four wire 1394 cable either, so I really don’t know the answer. Any easy (I assume) way to test the cable
and controllers would be to set up a 1394 network connection between the host and target (be sure to reenable the controllers before
doing so), but the problem is that I’m not sure what the necessarily says about how the components are functioning from WinDbg’s
point of view, unless they fail to work at all. Otherwise, it’s definitely possible that the target controller isn’t supported, and
as I said, I don’t know what the deal with a four wire cable is.

Just to reiterate, I would seriously consider purchasing a known good laptop compatible 1394 card for the target before I did
anything else.

Good luck,

mm

xxxxx@gmail.com wrote:

Thanks for the hints, i tried them but still the state is same. I am not sure if my wire, ports are in good order.Please suggest any way to test the ports and wire.

Is it necessary to have SP1 only to proceed with debugging?

Thanks in advance…

Regards,
Pranav

Ken_Johnson · October 6, 2008, 11:29am

I seem to recall that there were some enhancements to 1394 debugging in either XP SP1 or XP SP2, and that before the enhancements, you really did have to disable the 1394 controller in the target.

SP2 / SP3 definitely don’t require this, though, as they use the “new way” of things.

/DEBUG is definitely required here, and it’s not implied by /DEBUGPORT, at least, not the last time I looked at ntoskrnl.exe.

The (only) 1394 debugging I have done has been with 4-pin connectors (or 4-pin to 6-pin adapters, for one particular tower desktop target); it’ll work fine with the 4-pin flavors of 1394.

You can also use Ctrl-Alt-D to toggle debug output relating to the kernel debugger connection in KD, but without /DEBUG being set in your boot.ini, I’m pretty sure that all it will show is that DbgEng is waiting for a response from the other side.

S

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Monday, October 06, 2008 8:06 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] 1394 Debug problem using WinXP SP3

Is SP1 required for debugging on XP? Most definitely not. Although I’ve never debugged an SP3 machine, I’ve also never debugged a
SP1 machine either, so I can only personally confirm that debugging of SP2 definitely works. I’m not sure where you got the SP1
idea, but I seriously doubt that it’s correct.

I’ve also never used a four wire 1394 cable either, so I really don’t know the answer. Any easy (I assume) way to test the cable
and controllers would be to set up a 1394 network connection between the host and target (be sure to reenable the controllers before
doing so), but the problem is that I’m not sure what the necessarily says about how the components are functioning from WinDbg’s
point of view, unless they fail to work at all. Otherwise, it’s definitely possible that the target controller isn’t supported, and
as I said, I don’t know what the deal with a four wire cable is.

Just to reiterate, I would seriously consider purchasing a known good laptop compatible 1394 card for the target before I did
anything else.

Good luck,

mm

xxxxx@gmail.com wrote:

Thanks for the hints, i tried them but still the state is same. I am not sure if my wire, ports are in good order.Please suggest any way to test the ports and wire.

Is it necessary to have SP1 only to proceed with debugging?

Thanks in advance…

Regards,
Pranav

You are currently subscribed to windbg as: xxxxx@valhallalegends.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Don_Burn_1 · October 6, 2008, 11:41am

Ken,

/debug has always been (at least NT 3.5 on) auto-implied in the ntldr
with /debugport or /baudrate. I have not done a lot with SP3 but I find
this hard to believe it is now a requirement.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Skywing” wrote in message
news:xxxxx@windbg…
I seem to recall that there were some enhancements to 1394 debugging in
either XP SP1 or XP SP2, and that before the enhancements, you really did
have to disable the 1394 controller in the target.

SP2 / SP3 definitely don’t require this, though, as they use the “new way”
of things.

/DEBUG is definitely required here, and it’s not implied by /DEBUGPORT, at
least, not the last time I looked at ntoskrnl.exe.

The (only) 1394 debugging I have done has been with 4-pin connectors (or
4-pin to 6-pin adapters, for one particular tower desktop target); it’ll
work fine with the 4-pin flavors of 1394.

You can also use Ctrl-Alt-D to toggle debug output relating to the kernel
debugger connection in KD, but without /DEBUG being set in your boot.ini,
I’m pretty sure that all it will show is that DbgEng is waiting for a
response from the other side.

- S

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Monday, October 06, 2008 8:06 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] 1394 Debug problem using WinXP SP3

Is SP1 required for debugging on XP? Most definitely not. Although I’ve
never debugged an SP3 machine, I’ve also never debugged a
SP1 machine either, so I can only personally confirm that debugging of SP2
definitely works. I’m not sure where you got the SP1
idea, but I seriously doubt that it’s correct.

I’ve also never used a four wire 1394 cable either, so I really don’t know
the answer. Any easy (I assume) way to test the cable
and controllers would be to set up a 1394 network connection between the
host and target (be sure to reenable the controllers before
doing so), but the problem is that I’m not sure what the necessarily says
about how the components are functioning from WinDbg’s
point of view, unless they fail to work at all. Otherwise, it’s definitely
possible that the target controller isn’t supported, and
as I said, I don’t know what the deal with a four wire cable is.

Just to reiterate, I would seriously consider purchasing a known good laptop
compatible 1394 card for the target before I did
anything else.

Good luck,

mm

xxxxx@gmail.com wrote:
> Thanks for the hints, i tried them but still the state is same. I am not
> sure if my wire, ports are in good order.Please suggest any way to test
> the ports and wire.
>
> Is it necessary to have SP1 only to proceed with debugging?
>
> Thanks in advance…
>
> Regards,
> Pranav
>

—
You are currently subscribed to windbg as: xxxxx@valhallalegends.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Ken_Johnson · October 6, 2008, 11:55am

Double checked, and it seems like /debugport will indeed enable KD alone (without /debug), though it’s pretty arguably that it’s purely by accident, as the actual check is a strstr(“DEBUG”) (after checks for strstr(“CRASHDEBUG”) and strstr(“DEBUGPORT”). I would tend to write it off as a side-effect of the (very) poor-man command line parsing than a supported feature.

That being said, however, it looks like it’ll still enable KD in current OS builds. Not sure if the BCD-style (Vista and beyond) boot loader will append /DEBUGPORT to the osloader command line if it doesn’t see the appropriate BCD registry setting for debugging enabled, though.

S

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Monday, October 06, 2008 11:41 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Re:1394 Debug problem using WinXP SP3

Ken,

/debug has always been (at least NT 3.5 on) auto-implied in the ntldr
with /debugport or /baudrate. I have not done a lot with SP3 but I find
this hard to believe it is now a requirement.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Skywing” wrote in message
news:xxxxx@windbg…
I seem to recall that there were some enhancements to 1394 debugging in
either XP SP1 or XP SP2, and that before the enhancements, you really did
have to disable the 1394 controller in the target.

SP2 / SP3 definitely don’t require this, though, as they use the “new way”
of things.

/DEBUG is definitely required here, and it’s not implied by /DEBUGPORT, at
least, not the last time I looked at ntoskrnl.exe.

The (only) 1394 debugging I have done has been with 4-pin connectors (or
4-pin to 6-pin adapters, for one particular tower desktop target); it’ll
work fine with the 4-pin flavors of 1394.

You can also use Ctrl-Alt-D to toggle debug output relating to the kernel
debugger connection in KD, but without /DEBUG being set in your boot.ini,
I’m pretty sure that all it will show is that DbgEng is waiting for a
response from the other side.

- S

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Monday, October 06, 2008 8:06 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] 1394 Debug problem using WinXP SP3

Is SP1 required for debugging on XP? Most definitely not. Although I’ve
never debugged an SP3 machine, I’ve also never debugged a
SP1 machine either, so I can only personally confirm that debugging of SP2
definitely works. I’m not sure where you got the SP1
idea, but I seriously doubt that it’s correct.

I’ve also never used a four wire 1394 cable either, so I really don’t know
the answer. Any easy (I assume) way to test the cable
and controllers would be to set up a 1394 network connection between the
host and target (be sure to reenable the controllers before
doing so), but the problem is that I’m not sure what the necessarily says
about how the components are functioning from WinDbg’s
point of view, unless they fail to work at all. Otherwise, it’s definitely
possible that the target controller isn’t supported, and
as I said, I don’t know what the deal with a four wire cable is.

Just to reiterate, I would seriously consider purchasing a known good laptop
compatible 1394 card for the target before I did
anything else.

Good luck,

mm

xxxxx@gmail.com wrote:
> Thanks for the hints, i tried them but still the state is same. I am not
> sure if my wire, ports are in good order.Please suggest any way to test
> the ports and wire.
>
> Is it necessary to have SP1 only to proceed with debugging?
>
> Thanks in advance…
>
> Regards,
> Pranav
>

—
You are currently subscribed to windbg as: xxxxx@valhallalegends.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
You are currently subscribed to windbg as: xxxxx@valhallalegends.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Tim_Roberts · October 6, 2008, 12:49pm

Martin O’Brien wrote:

You don’t have ‘/DEBUG’ in your boot.ini file. I don’t know whether
you will be able to connect with WinDbg without it (perhaps /debugport
implies /debug, but I kind of doubt it),

Yes, it does. Adding any debugger option automatically enables /debug.
Always has.

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

Tim_Roberts · October 6, 2008, 12:52pm

Skywing wrote:

Double checked, and it seems like /debugport will indeed enable KD alone (without /debug), though it’s pretty arguably that it’s purely by accident, as the actual check is a strstr(“DEBUG”) (after checks for strstr(“CRASHDEBUG”) and strstr(“DEBUGPORT”). I would tend to write it off as a side-effect of the (very) poor-man command line parsing than a supported feature.

Nonsense. It is a documented and supported feature of boot.ini, and
always has been. The fact that you’ve never encountered it doesn’t make
it dangerous.

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

OSR_Community_User · October 6, 2008, 1:10pm

Thanks to all for looking into the issue,but i am still unable to debug.
As suggested i have enabled all 1394 port and hosts, the current target settings (added by msconfig )are as follows:

[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=“Microsoft Windows XP Professional” /noexecute=optin /fastdetect /debug /debugport=1394 /channel=2

Still host is “waiting to connect”, any more guidelines to track the issues are welcome. I tried break , Ctrl+Alt+d and Ctrl+Alt+r also.

Regards,
Pranav

Ken_Johnson · October 6, 2008, 1:21pm

I didn’t indicate that it was “dangerous” because I had never encountered it before.

/DEBUGPORT is processed at the kd transport dll layer (e.g. kdcom.dll, kdusb.dll, kd1394.dll, and soforth.) /DEBUG is processed by the kernel itself. These components are at different levels of abstraction. Aside from the special checks beforehand about /CRASHDEBUG and /NODEBUG, if the kernel finds the string “/DEBUG” in the osloader command line, it’ll enable KD.

Now, it might be that this is behavior documented somewhere - (although all of the documentation I can find doesn’t make any mention of it at all, though I’m certainly willing to accept that someone documented it long ago, or that one of the many places where the osloader switches are documented says something slightly different) - and it might never change at this point in the game, but I remain a lil bit skeptical that it’s by anything other than accident that it happened to work other than that the naming of the parameters and a quirk of how the osloader options happen to be parsed lead to that result.

Conceptually, /DEBUGPORT is a kd transport-layer module specific option, and it’s not something the kernel (tries) to parse at all explicitly, aside from the fact that it just happened to work out that passing /DEBUGPORT fools the KdInitSystem parser into thinking you sent /DEBUG. (And maybe intentionally, but I remain skeptical.) It would be conceivable that there could be a kd transport module which doesn’t use /DEBUGPORT at all but some completely different argument, and that would work fine, since the kernel is (aside from the aliasing due to the substr check) agnostic of /DEBUGPORT.

It might well be that it’ll never change, but it still smacks of relying on an implementation quirk to me, which is something I tend to find a bit less than desirable, to say the least.

S

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Monday, October 06, 2008 12:51 PM
To: Kernel Debugging Interest List
Subject: Re: [windbg] Re:1394 Debug problem using WinXP SP3

Skywing wrote:

Double checked, and it seems like /debugport will indeed enable KD alone (without /debug), though it’s pretty arguably that it’s purely by accident, as the actual check is a strstr(“DEBUG”) (after checks for strstr(“CRASHDEBUG”) and strstr(“DEBUGPORT”). I would tend to write it off as a side-effect of the (very) poor-man command line parsing than a supported feature.

Nonsense. It is a documented and supported feature of boot.ini, and
always has been. The fact that you’ve never encountered it doesn’t make
it dangerous.

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

You are currently subscribed to windbg as: xxxxx@valhallalegends.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Jen-Lung_Chiu-2 · October 6, 2008, 1:21pm

What is the windbg output before “waiting to connect”? Did it match the target configuration?

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Monday, October 06, 2008 10:11 AM
To: Kernel Debugging Interest List
Subject: RE:[windbg] 1394 Debug problem using WinXP SP3

Thanks to all for looking into the issue,but i am still unable to debug.
As suggested i have enabled all 1394 port and hosts, the current target settings (added by msconfig )are as follows:

[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=“Microsoft Windows XP Professional” /noexecute=optin /fastdetect /debug /debugport=1394 /channel=2

Still host is “waiting to connect”, any more guidelines to track the issues are welcome. I tried break , Ctrl+Alt+d and Ctrl+Alt+r also.

Regards,
Pranav

You are currently subscribed to windbg as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · October 6, 2008, 1:44pm

Microsoft Windows Debugger Version 6.8.0004 0 X86
CopyRight

Using 1394 for debugging
Opened \.\DBG1394_CHANNEL02
Waiting to reconnect…
Will request initial breakpoint at next boot

Regards,
Pranav

Jen-Lung_Chiu-2 · October 6, 2008, 1:58pm

Thanks, the settings between the host debugger and target matches.

What is the 1394 controller chipset at the target machine?
Did you try with different target machines? Different cables?

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Monday, October 06, 2008 10:45 AM
To: Kernel Debugging Interest List
Subject: RE:[windbg] 1394 Debug problem using WinXP SP3

Microsoft Windows Debugger Version 6.8.0004 0 X86
CopyRight

Using 1394 for debugging
Opened \.\DBG1394_CHANNEL02
Waiting to reconnect…
Will request initial breakpoint at next boot

Regards,
Pranav

You are currently subscribed to windbg as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · October 6, 2008, 2:06pm

Those aren’t the same as what you posted for the boot.ini (different channels):

Boot.ini :
multi(0)disk(0)rdisk(0)partition(1)\windows=“Microsoft Windows XP(1394)”
/fastdetect /debugport=1394 /channel=5

Did you change the channel number on the command line as well? I imagine you did, because I don’t think that you would be able to
get this far if they didn’t match, but I’m not sure, so I thought I would mention it.

What is the brand, model number and ideally the chipset manufacturer of the 1394 controller you’re using on the target?

1394 CARDBUS ADAPTER: $34

https://www.osronline.com/custom.cfm?name=index_fullframeset.cfm&pageURL=https://www.osronline.com/store/index.cfm

Good luck,

mm

xxxxx@gmail.com wrote:

Microsoft Windows Debugger Version 6.8.0004 0 X86
CopyRight

Using 1394 for debugging
Opened \.\DBG1394_CHANNEL02
Waiting to reconnect…
Will request initial breakpoint at next boot

Regards,
Pranav

Crispin_Wright · October 6, 2008, 2:19pm

Pranav,

It’s stating the obvious I know, but have you checked that the 1394 cable is
functioning correctly?

I had this problem a few weeks ago - debugging without issue on Monday -
went to client site Tuesday, with cable coiled in my bag - tried to debug on
Wednesday, and the cable was shagged due to my enthusiastic coiling
efforts…

C

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: 06 October 2008 18:11
To: Kernel Debugging Interest List
Subject: RE:[windbg] 1394 Debug problem using WinXP SP3

Thanks to all for looking into the issue,but i am still unable to debug.
As suggested i have enabled all 1394 port and hosts, the current target
settings (added by msconfig )are as follows:

[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=“Microsoft Windows XP
Professional” /noexecute=optin /fastdetect /debug /debugport=1394 /channel=2

Still host is “waiting to connect”, any more guidelines to track the issues
are welcome. I tried break , Ctrl+Alt+d and Ctrl+Alt+r also.

Regards,
Pranav

You are currently subscribed to windbg as: xxxxx@blocksoft.co.uk
To unsubscribe send a blank email to xxxxx@lists.osr.com

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 3497 (20081006) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 3497 (20081006) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

OSR_Community_User · October 6, 2008, 2:42pm

Dear All,

Thanks to all for the valuable inputs.

I re checked , i am using Channel 2 on both of the machines.

Did anybody got Windbg working on IEEE 1394 On WnXP SP3 on both host and targets??

Regards,
Pranav

Tim_Roberts · October 6, 2008, 4:16pm

xxxxx@gmail.com wrote:

Dear All,

Thanks to all for the valuable inputs.

I re checked , i am using Channel 2 on both of the machines.

Did anybody got Windbg working on IEEE 1394 On WnXP SP3 on both host and targets??

Yes, I have. (As it turns out, I have NOT been able to do an
XPSP3->Vista connection, but XPSP3->XPSP3 is fine.) If you read the
archives, you’ll that success depends very much on the brand of the 1394
host controller.

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