How to uninstall 1394 debugger device

Hi,

I have to PC's where my firewire card has been unavailable after installing
MS Debugging tools 6.5.3.7.
It seems that the drivers "1394 Host Debugger I/O Driver" and "1394 Windows
Debug Driver(Kernel Mode)" is stopping the card from working.

The problem is that it seems impossible to unstall the drivers/software !!

Please help
Thank you in advance.
Peter

Peter
Fri Oct 14 12:32:27 CDT 2005

btw, to = two

fat_boy
Mon Oct 17 07:28:24 CDT 2005

The documentation says to disable the 1394 port before using it to
debug. I found that not to be true. But, when the debugger IS using
it it is disabled.

Create a second boot.ini option which is not debug enabled. If you
want to use the 1394 port, boot into that instead of the debug enabled
windows.

Bill
Mon Oct 17 18:35:17 CDT 2005

If you have debugging enabled *and* you have specified the debugging port as
1394 *and* you have only one 1394 host controller in the system then you
will not be able to use the 1394 ports on that system. However, if you do
not have debugging enabled, or you have debugging enabled and you specified
the debugging port as COMx, or you have debugging enabled and you specified
the port as 1394 but you have another 1394 host controller on the system,
then you should be able to operate 1394 devices in parallel with your kernel
debugger just fine.

Bill M.

"fat_boy" <m.sykes@option.com> wrote in message
news:1129552104.432794.88970@f14g2000cwb.googlegroups.com...
> The documentation says to disable the 1394 port before using it to
> debug. I found that not to be true. But, when the debugger IS using
> it it is disabled.
>
> Create a second boot.ini option which is not debug enabled. If you
> want to use the 1394 port, boot into that instead of the debug enabled
> windows.
>

r_konjeti
Tue Oct 18 14:52:07 CDT 2005

I dont know why is it necessary to have exclusive access for
WinDbg(even when not running) to the debugport(not only 1394 this is
the case with COM port also). Sure they have a good reason for that,
just interested to know why they implemented it that way. Cant they
have some way to get exclusive access only when debugger is running
rather than host never having access to the port if booted this way.

Thanks

Bill McKenzie wrote:
> If you have debugging enabled *and* you have specified the debugging port as
> 1394 *and* you have only one 1394 host controller in the system then you
> will not be able to use the 1394 ports on that system. However, if you do
> not have debugging enabled, or you have debugging enabled and you specified
> the debugging port as COMx, or you have debugging enabled and you specified
> the port as 1394 but you have another 1394 host controller on the system,
> then you should be able to operate 1394 devices in parallel with your kernel
> debugger just fine.
>
> Bill M.
>
> "fat_boy" <m.sykes@option.com> wrote in message
> news:1129552104.432794.88970@f14g2000cwb.googlegroups.com...
> > The documentation says to disable the 1394 port before using it to
> > debug. I found that not to be true. But, when the debugger IS using
> > it it is disabled.
> >
> > Create a second boot.ini option which is not debug enabled. If you
> > want to use the 1394 port, boot into that instead of the debug enabled
> > windows.
> >

Bill
Tue Oct 18 19:00:48 CDT 2005

Actually, you don't want it that way. If debugging is enabled, that means a
kernel debugger can hook up at anytime. If exclusive access to the debug
port were not available, you couldn't hook up the debugger. If you don't
want this, don't enable debugging.

Bill M.


<r_konjeti@mailcity.com> wrote in message
news:1129665127.330806.226440@o13g2000cwo.googlegroups.com...
>I dont know why is it necessary to have exclusive access for
> WinDbg(even when not running) to the debugport(not only 1394 this is
> the case with COM port also). Sure they have a good reason for that,
> just interested to know why they implemented it that way. Cant they
> have some way to get exclusive access only when debugger is running
> rather than host never having access to the port if booted this way.
>
> Thanks
>
> Bill McKenzie wrote:
>> If you have debugging enabled *and* you have specified the debugging port
>> as
>> 1394 *and* you have only one 1394 host controller in the system then you
>> will not be able to use the 1394 ports on that system. However, if you
>> do
>> not have debugging enabled, or you have debugging enabled and you
>> specified
>> the debugging port as COMx, or you have debugging enabled and you
>> specified
>> the port as 1394 but you have another 1394 host controller on the system,
>> then you should be able to operate 1394 devices in parallel with your
>> kernel
>> debugger just fine.
>>
>> Bill M.
>>
>> "fat_boy" <m.sykes@option.com> wrote in message
>> news:1129552104.432794.88970@f14g2000cwb.googlegroups.com...
>> > The documentation says to disable the 1394 port before using it to
>> > debug. I found that not to be true. But, when the debugger IS using
>> > it it is disabled.
>> >
>> > Create a second boot.ini option which is not debug enabled. If you
>> > want to use the 1394 port, boot into that instead of the debug enabled
>> > windows.
>> >
>

Pavel
Thu Oct 20 16:45:14 CDT 2005

<r_konjeti@mailcity.com> wrote in message news:1129665127.330806.226440@o13g2000cwo.googlegroups.com...
>I dont know why is it necessary to have exclusive access for
> WinDbg(even when not running) to the debugport( not only 1394 this is
> the case with COM port also).

?? When you don't run windbg, it won't grab the com port - so no
exclusive access. The port is free for anything else.

--PA

Maxim
Fri Oct 21 03:49:33 CDT 2005

> ?? When you don't run windbg, it won't grab the com port - so no
> exclusive access. The port is free for anything else.

Host side - yes, target side - no - the port hardware is exclusively owned by
KD.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

r_konjeti
Fri Oct 21 13:54:11 CDT 2005

Is there any reason why target should always hold on to its port. why
not target lock the port only when host is listening.

Maxim S. Shatskih wrote:
> > ?? When you don't run windbg, it won't grab the com port - so no
> > exclusive access. The port is free for anything else.
>
> Host side - yes, target side - no - the port hardware is exclusively owned by
> KD.
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com

Maxim
Fri Oct 21 15:42:06 CDT 2005

This is done to allow starting debugger on host much later, after the
target is booted.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

<r_konjeti@mailcity.com> wrote in message
news:1129920851.155937.268660@g43g2000cwa.googlegroups.com...
> Is there any reason why target should always hold on to its port. why
> not target lock the port only when host is listening.

Bill
Fri Oct 21 18:23:42 CDT 2005

> This is done to allow starting debugger on host much later, after the
> target is booted.

Isn't this basically what I already said? It is certainly what I intended.

Again, if you don't want the debugger taking exclusive access of the port do
not enable debugging. Why is this a problem for you?

Bill M.


"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:eOx$B$n1FHA.3376@TK2MSFTNGP14.phx.gbl...
> This is done to allow starting debugger on host much later, after the
> target is booted.
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com
>
> <r_konjeti@mailcity.com> wrote in message
> news:1129920851.155937.268660@g43g2000cwa.googlegroups.com...
>> Is there any reason why target should always hold on to its port. why
>> not target lock the port only when host is listening.
>
>

Pavel
Fri Oct 21 18:24:18 CDT 2005

<r_konjeti@mailcity.com> wrote in message news:1129920851.155937.268660@g43g2000cwa.googlegroups.com...
> Is there any reason why target should always hold on to its port. why
> not target lock the port only when host is listening.

Because one of debugging scenarios is that target starts without
host debugger connected; later when a breakpoint or other exception occurs, it will
wait for the host. So the port is always reserved.

--PA

Peter
Mon Oct 24 03:42:46 CDT 2005

Thank you for your time.

I have solved the problem by doing a "System Restore".
The firewire card was unavailable and i had to do something.

/Peter

"Pavel A." <pavel_a@NOwritemeNO.com> wrote in message
news:Of$9Tap1FHA.3204@TK2MSFTNGP14.phx.gbl...
> <r_konjeti@mailcity.com> wrote in message
> news:1129920851.155937.268660@g43g2000cwa.googlegroups.com...
>> Is there any reason why target should always hold on to its port. why
>> not target lock the port only when host is listening.
>
> Because one of debugging scenarios is that target starts without
> host debugger connected; later when a breakpoint or other exception
> occurs, it will
> wait for the host. So the port is always reserved.
>
> --PA
>
>
>
>