Several times in the midst of a debugging session, WinDbg shows that it
thinks it still has a connection, yet debug spew from the machine under test
is not appearing in the command window.
If a breakpoint or BSOD occurs, the machine under test hangs, but WinDbg
does get control.
Shutting down and restarting WinDbg results in an inablity to connect up
with the machine under test, no matter how many breaks it sends out over the
connection.
This behaviour was noted intermittently using 6.0.17 but has increased in
the new build.
Another interesting side note, if the Break is sent from restarted WinDbg
and that debug session is left open whilst the machine under test if reset,
the testbed will acknowledge the break as it is rebooting.
“Del Fredricks” wrote in message
news:xxxxx@windbg…
>
> Several times in the midst of a debugging session, WinDbg shows that it
> thinks it still has a connection, yet debug spew from the machine under
test
> is not appearing in the command window.
>
> If a breakpoint or BSOD occurs, the machine under test hangs, but WinDbg
> does get control.
>
> Shutting down and restarting WinDbg results in an inablity to connect up
> with the machine under test, no matter how many breaks it sends out over
the
> connection.
>
> This behaviour was noted intermittently using 6.0.17 but has increased in
> the new build.
>
>
>
>
Hi,
I had a problem with 1394 debugging with SP1 where the debug connect would
be dropped and like you any breaks appeared to be stored up on the host
system and would cause breaks after the target had rebooted.
The solution for me was to disable the 1394 controller in the device
manager, this does not effect 1394 debugging.
Yours
Roger
Roger Coote,
Senior Design Engineer
PowerVR Technologies, A Division of Imagination Technologies Ltd
Home Park Estate, Kings Langley, Hertfordshire, WD4 8LZ, UK
phone :+44 (1923) 260511 fax :+44 (1923) 268969
direct :+44 (1923) 277274
mailto:xxxxx@powervr.com www.powervr.com
-----Original Message-----
From: Del Fredricks [mailto:xxxxx@comtrol.com]
Sent: 15 October 2002 18:31
To: Kernel Debugging Interest List
Subject: [windbg] Re: 6.1.9 arbitrarily drops 1394 connection!!!
Another interesting side note, if the Break is sent from restarted WinDbg
and that debug session is left open whilst the machine under test if reset,
the testbed will acknowledge the break as it is rebooting.
“Del Fredricks” wrote in message
news:xxxxx@windbg…
>
> Several times in the midst of a debugging session, WinDbg shows that it
> thinks it still has a connection, yet debug spew from the machine under
test
> is not appearing in the command window.
>
> If a breakpoint or BSOD occurs, the machine under test hangs, but WinDbg
> does get control.
>
> Shutting down and restarting WinDbg results in an inablity to connect up
> with the machine under test, no matter how many breaks it sends out over
the
> connection.
>
> This behaviour was noted intermittently using 6.0.17 but has increased in
> the new build.
>
>
>
>
—
You are currently subscribed to windbg as: xxxxx@videologic.com
To unsubscribe send a blank email to %%email.unsub%%
This is precisely what I am seeing. One question, did you disable the 1394
controller in the device manager on which system Host or machine under test?
“Roger Coote” wrote in message news:xxxxx@windbg…
>
> Hi,
> I had a problem with 1394 debugging with SP1 where the debug connect would
> be dropped and like you any breaks appeared to be stored up on the host
> system and would cause breaks after the target had rebooted.
>
> The solution for me was to disable the 1394 controller in the device
> manager, this does not effect 1394 debugging.
>
> Yours
> Roger
>
>
> Roger Coote,
> Senior Design Engineer
> PowerVR Technologies, A Division of Imagination Technologies Ltd
> Home Park Estate, Kings Langley, Hertfordshire, WD4 8LZ, UK
> phone :+44 (1923) 260511 fax :+44 (1923) 268969
> direct :+44 (1923) 277274
> mailto:xxxxx@powervr.com www.powervr.com
>
>
>
>
> -----Original Message-----
> From: Del Fredricks [mailto:xxxxx@comtrol.com]
> Sent: 15 October 2002 18:31
> To: Kernel Debugging Interest List
> Subject: [windbg] Re: 6.1.9 arbitrarily drops 1394 connection!!!
>
>
>
> Another interesting side note, if the Break is sent from restarted WinDbg
> and that debug session is left open whilst the machine under test if
reset,
> the testbed will acknowledge the break as it is rebooting.
>
> “Del Fredricks” wrote in message
> news:xxxxx@windbg…
> >
> > Several times in the midst of a debugging session, WinDbg shows that it
> > thinks it still has a connection, yet debug spew from the machine under
> test
> > is not appearing in the command window.
> >
> > If a breakpoint or BSOD occurs, the machine under test hangs, but WinDbg
> > does get control.
> >
> > Shutting down and restarting WinDbg results in an inablity to connect up
> > with the machine under test, no matter how many breaks it sends out over
> the
> > connection.
> >
> > This behaviour was noted intermittently using 6.0.17 but has increased
in
> > the new build.
> >
> >
> >
> >
>
>
>
> —
> You are currently subscribed to windbg as: xxxxx@videologic.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
>
I had serious problems with the new build when using a 1394
connection. WinDbg -d will no longer break during target boot and the
target will hang at boot if /DebugBreak is placed on the BOOT.INI
line.
I had to revert back to 6.0.17.0.
…John
On Tue, 15 Oct 2002 12:23:50 -0500, “Del Fredricks”
wrote:
>
>Several times in the midst of a debugging session, WinDbg shows that it
>thinks it still has a connection, yet debug spew from the machine under test
>is not appearing in the command window.
>
>If a breakpoint or BSOD occurs, the machine under test hangs, but WinDbg
>does get control.
>
>Shutting down and restarting WinDbg results in an inablity to connect up
>with the machine under test, no matter how many breaks it sends out over the
>connection.
>
>This behaviour was noted intermittently using 6.0.17 but has increased in
>the new build.
>
>
>
Hi,
I disabled 1394 controller on the target system.
Yours
Roger
Roger Coote,
Senior Design Engineer
PowerVR Technologies, A Division of Imagination Technologies Ltd
Home Park Estate, Kings Langley, Hertfordshire, WD4 8LZ, UK
phone :+44 (1923) 260511 fax :+44 (1923) 268969
direct :+44 (1923) 277274
mailto:xxxxx@powervr.com www.powervr.com
-----Original Message-----
From: Del Fredricks [mailto:xxxxx@comtrol.com]
Sent: 15 October 2002 21:34
To: Kernel Debugging Interest List
Subject: [windbg] Re: 6.1.9 arbitrarily drops 1394 connection!!!
This is precisely what I am seeing. One question, did you disable the 1394
controller in the device manager on which system Host or machine under test?
“Roger Coote” wrote in message news:xxxxx@windbg…
>
> Hi,
> I had a problem with 1394 debugging with SP1 where the debug connect would
> be dropped and like you any breaks appeared to be stored up on the host
> system and would cause breaks after the target had rebooted.
>
> The solution for me was to disable the 1394 controller in the device
> manager, this does not effect 1394 debugging.
>
> Yours
> Roger
>
>
> Roger Coote,
> Senior Design Engineer
> PowerVR Technologies, A Division of Imagination Technologies Ltd
> Home Park Estate, Kings Langley, Hertfordshire, WD4 8LZ, UK
> phone :+44 (1923) 260511 fax :+44 (1923) 268969
> direct :+44 (1923) 277274
> mailto:xxxxx@powervr.com www.powervr.com
>
>
>
>
> -----Original Message-----
> From: Del Fredricks [mailto:xxxxx@comtrol.com]
> Sent: 15 October 2002 18:31
> To: Kernel Debugging Interest List
> Subject: [windbg] Re: 6.1.9 arbitrarily drops 1394 connection!!!
>
>
>
> Another interesting side note, if the Break is sent from restarted WinDbg
> and that debug session is left open whilst the machine under test if
reset,
> the testbed will acknowledge the break as it is rebooting.
>
> “Del Fredricks” wrote in message
> news:xxxxx@windbg…
> >
> > Several times in the midst of a debugging session, WinDbg shows that it
> > thinks it still has a connection, yet debug spew from the machine under
> test
> > is not appearing in the command window.
> >
> > If a breakpoint or BSOD occurs, the machine under test hangs, but WinDbg
> > does get control.
> >
> > Shutting down and restarting WinDbg results in an inablity to connect up
> > with the machine under test, no matter how many breaks it sends out over
> the
> > connection.
> >
> > This behaviour was noted intermittently using 6.0.17 but has increased
in
> > the new build.
> >
> >
> >
> >
>
>
>
> —
> You are currently subscribed to windbg as: xxxxx@videologic.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
>
—
You are currently subscribed to windbg as: xxxxx@videologic.com
To unsubscribe send a blank email to %%email.unsub%%
Thanks, I found that by disabling on the test system that I was able to
connect more frequently when booting. However, I am finding that the
connection still drops at some point with neither side aware that the
connection was lost. This is evidenced by that fact that debug outputs do
not make it to the debugger and breaks from the debugger do no halt the test
system.
“Roger Coote” wrote in message news:xxxxx@windbg…
>
> Hi,
> I disabled 1394 controller on the target system.
>
> Yours
> Roger
>
>
> Roger Coote,
> Senior Design Engineer
> PowerVR Technologies, A Division of Imagination Technologies Ltd
> Home Park Estate, Kings Langley, Hertfordshire, WD4 8LZ, UK
> phone :+44 (1923) 260511 fax :+44 (1923) 268969
> direct :+44 (1923) 277274
> mailto:xxxxx@powervr.com www.powervr.com
>
>
>
>
> -----Original Message-----
> From: Del Fredricks [mailto:xxxxx@comtrol.com]
> Sent: 15 October 2002 21:34
> To: Kernel Debugging Interest List
> Subject: [windbg] Re: 6.1.9 arbitrarily drops 1394 connection!!!
>
>
> This is precisely what I am seeing. One question, did you disable the
1394
> controller in the device manager on which system Host or machine under
test?
>
> “Roger Coote” wrote in message
news:xxxxx@windbg…
> >
> > Hi,
> > I had a problem with 1394 debugging with SP1 where the debug connect
would
> > be dropped and like you any breaks appeared to be stored up on the host
> > system and would cause breaks after the target had rebooted.
> >
> > The solution for me was to disable the 1394 controller in the device
> > manager, this does not effect 1394 debugging.
> >
> > Yours
> > Roger
> >
> >
> > Roger Coote,
> > Senior Design Engineer
> > PowerVR Technologies, A Division of Imagination Technologies Ltd
> > Home Park Estate, Kings Langley, Hertfordshire, WD4 8LZ, UK
> > phone :+44 (1923) 260511 fax :+44 (1923) 268969
> > direct :+44 (1923) 277274
> > mailto:xxxxx@powervr.com www.powervr.com
> >
> >
> >
> >
> > -----Original Message-----
> > From: Del Fredricks [mailto:xxxxx@comtrol.com]
> > Sent: 15 October 2002 18:31
> > To: Kernel Debugging Interest List
> > Subject: [windbg] Re: 6.1.9 arbitrarily drops 1394 connection!!!
> >
> >
> >
> > Another interesting side note, if the Break is sent from restarted
WinDbg
> > and that debug session is left open whilst the machine under test if
> reset,
> > the testbed will acknowledge the break as it is rebooting.
> >
> > “Del Fredricks” wrote in message
> > news:xxxxx@windbg…
> > >
> > > Several times in the midst of a debugging session, WinDbg shows that
it
> > > thinks it still has a connection, yet debug spew from the machine
under
> > test
> > > is not appearing in the command window.
> > >
> > > If a breakpoint or BSOD occurs, the machine under test hangs, but
WinDbg
> > > does get control.
> > >
> > > Shutting down and restarting WinDbg results in an inablity to connect
up
> > > with the machine under test, no matter how many breaks it sends out
over
> > the
> > > connection.
> > >
> > > This behaviour was noted intermittently using 6.0.17 but has increased
> in
> > > the new build.
> > >
> > >
> > >
> > >
> >
> >
> >
> > —
> > You are currently subscribed to windbg as: xxxxx@videologic.com
> > To unsubscribe send a blank email to %%email.unsub%%
> >
> >
> >
>
>
>
> —
> You are currently subscribed to windbg as: xxxxx@videologic.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
>