1394 debugging broke suddenly

Between one debug session (a few months ago, I have to admit) and today, my
1394 debugging capability went away. My present symptom (with WinDbg v.
6.11.0001.404 x86) is an E000020B (ERROR_NO_SUCH_DEVINST) trying to install
“1394 device driver”. This is on an XP SP-3 host with a VIA 1394 card.

I have already searched the archives on this. There is a single cable from
the 1394 adapter connecting to a target computer which is currently off. On
the host machine, I tried disabling and re-enabling the 1394 controller. I
tried uninstalling the 1394 controller and rebooting (as recommended by the
WinDbg messages). I uninstalled and re-installed WinDbg. I looked for the
“safely remove hardware” icon that one archive post mentions, but it ain’t
there. I looked in device manager “view by connection” and found no
sub-devices under the 1394 controller. The drivers directory has 1394bus,
1394dbg1, and 1394dbg2 files with dates of 4/13/08, 7/7/06, and 9/15/05,
respectively. (These are versions 5.1.2600.5512, 6.0.5228.0, and 6.0.5228.0,
also respectively.)

After looking at the 1394dbg.inf file that’s part of the WinDbg package, I
tried deleting enum\v1394. That didn’t help, and that key didn’t come back
when I tried to start WinDbg afterwards. Evidently, WinDbg is trying to
install the 1394debug device as a PnP device, but whoever is supposed to be
enumerating a device with the right hardware id isn’t doing it.

Walter Oney
Consulting and Training
www.oneysoft.com

I have found that the only good 1394a chipset is from TI. It just always
works and remains reliable. It is not so much for the host as the target as
sometimes you can’t choose your chipset on notebooks that I usually use as a
host.

I would suggest reinstalling the OS on the host with no 1394a chipset
installed until the OS installation and Windows Update has been completed.
When installing the network ensure you uncheck all boxes for the 1394a (if
it is a LOM on the motherboard) and later, just disable the network based
1394 connection in the “My Network Places”. Microsoft recently replaced the
1394 drivers with the last one or two versions of Windbg. There is a readme
about some earlier versions not being replaced correctly by the installer.
Doing the reinstall will eliminate this problem or you could try doing what
it suggests.

Install the new windbg and use device tree to see if the debug devices are
visible. Do not install any other type of device on any port of the 1394a
controller used by windbg. The latest drivers for windbg are ‘supposed’ to
provide support for more 1394a chipsets, but I am just too paranoid and
careful. I have to serial far too often, but I do prefer 1394 except for
sleep/hibernate issues prior to Win 7. It does appear that a 1394a
connection will survive hibernation and sleep cycles if the target is
running Win 7. Only serial works for earlier versions of Windows.

P.S. I found a Belkin 1394a cable that is 10’ and has two adapters in the
package that convert from 6-pin to 4-pin so you can use it for any 1394a
host and target combination without having to keep three different cables
available. It costs about $20 at Fry’s Electronics. Pyro has a good 1394a
TI chipset PCI card that works in PCI and PCI-X slots. Otherwise the card
from OSR is very good, but it will not fit into a PCI-X slot. There is a
good PCIe X1 card with the TI chipset also available from Newegg.

“Walter Oney” wrote in message news:xxxxx@ntdev…
> Between one debug session (a few months ago, I have to admit) and today,
> my
> 1394 debugging capability went away. My present symptom (with WinDbg v.
> 6.11.0001.404 x86) is an E000020B (ERROR_NO_SUCH_DEVINST) trying to
> install
> “1394 device driver”. This is on an XP SP-3 host with a VIA 1394 card.
>
> I have already searched the archives on this. There is a single cable from
> the 1394 adapter connecting to a target computer which is currently off.
> On
> the host machine, I tried disabling and re-enabling the 1394 controller. I
> tried uninstalling the 1394 controller and rebooting (as recommended by
> the
> WinDbg messages). I uninstalled and re-installed WinDbg. I looked for the
> “safely remove hardware” icon that one archive post mentions, but it ain’t
> there. I looked in device manager “view by connection” and found no
> sub-devices under the 1394 controller. The drivers directory has 1394bus,
> 1394dbg1, and 1394dbg2 files with dates of 4/13/08, 7/7/06, and 9/15/05,
> respectively. (These are versions 5.1.2600.5512, 6.0.5228.0, and
> 6.0.5228.0,
> also respectively.)
>
> After looking at the 1394dbg.inf file that’s part of the WinDbg package, I
> tried deleting enum\v1394. That didn’t help, and that key didn’t come back
> when I tried to start WinDbg afterwards. Evidently, WinDbg is trying to
> install the 1394debug device as a PnP device, but whoever is supposed to
> be
> enumerating a device with the right hardware id isn’t doing it.
>
> Walter Oney
> Consulting and Training
> www.oneysoft.com
>
>

I agree with David about the TI chipset, but it sounds like it’s the host controller that’s at issue, so it shouldn’t matter.

Supposedly windbg now (since the one before 6.11.1.404 that was pretty much still born, if I recall correctly) supports all 1394 controllers in the target:

relnotes.txt:

There are many improvements that have been made in the 1394 debug driver
including changes to allow all 1394 cards to work in target machines.

However, the rest of the paragraph details the problem that I think you might be having:

This release of the debugger will not work well for 1394 kernel debugging if
it calls an old version of the driver from a previous release. The debugger
will check whether the 1394 driver is new enough, and if not, will install
the latest driver when 1394 debugging is started. There are 2 older versions
of the driver that will not get upgraded by this process. They are named
1394dbg1.sys and 1394dbg2.sys. They should be removed manually from the
system if required. An explanation of how to do this is contained in the
known issues section. It is extremely important that users do not attempt
to prevent the upgrade to the latest 1394 driver, as 1394 kernel debugging
may not work AT ALL if the latest driver is not installed. Make sure if
you are prompted to reboot the machine during driver install, that you reboot
before attempting to do 1394 kernel debugging. To prevent having to reboot
your host, make sure that all instances of the debugger that are doing 1394
kernel debugging are closed before running this release of the debugger.

There are detailed instructions further down in relnotes.txt on how to remove these drivers.

I’m not sure that this is your issue, but it sounds like you shouldn’t have 1394dbg1.sys & 1394dbg2.sys installed. I know that it was working before, but I had that problem as well, and one day, I have no idea of why, it stopped working, though I don’t recall what error I was getting. In any case, although I didn’t bother to remove those drivers the first time I installed and it worked fine, I did have to go through those steps that day in order to get windbg to work again.

Good luck,

mm

From:
> There are detailed instructions further down in relnotes.txt on how to
> remove these drivers.

No joy. I deleted 1394dbg1 & 1394dbg2, uninstalled the 1394 controller, and
rebooted, all as suggested by relnotes. I get the same result. I also
removed the service entries for 1394dbg and 1394vdbg, which were pointing to
the old drivers. I’m still getting the same error.

The error code may be coming from UpdateDriverForPlugAndPlayDevices (which
is the only place it’s specifically mentioned in the doc). It would indicate
that there’s no DEVNODE with a device id matching the INF. Who is supposed
to be creating the DEVNODE? Because it would seem that they didn’t do it
right, or got prevented from doing it.

I tried using DEVCON to manually install 1394dbg.inf, and I made several
changes to the INF in order to address plausible parsing bugs in devcon, but
it still didn’t work.

Yessir, this progress stuff is sure good.

Walter Oney
Consulting and Training
www.oneysoft.com

Well, that’s about I have to offer, unfortunately, other than one last ditch question - are you installing x86 windbg on an x64 host?

Sorry I don’t have better,

mm

From:
> Well, that’s about I have to offer, unfortunately, other than one last
> ditch question - are you installing x86 windbg on an x64 host?

Nope. I’m installing the 32-bit debugger on a 32-bit XP box.

Walter Oney
Consulting and Training
www.oneysoft.com

I had such a range of experience with 1394 that I eventually gave up on it
unless there was no alternative. The variation of target os/windbg/1394
controller versions makes it a crap shoot if any particular match up works.
Mark Roddy

On Sat, Jul 25, 2009 at 4:57 PM, Walter Oney wrote:

> From:
>
>> Well, that’s about I have to offer, unfortunately, other than one last
>> ditch question - are you installing x86 windbg on an x64 host?
>>
>
> Nope. I’m installing the 32-bit debugger on a 32-bit XP box.
>
> Walter Oney
> Consulting and Training
> www.oneysoft.com
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

I have numerous experiences with this problem. I have searched the web in vain but only discovered other people are seeing it, but no workaround. I found that if I keep fiddling with things, unplugging/replugging the cable, restarting the debugger, restarting both systems, reinstalling the debugger, etc, etc eventually it magically starts working again. It can take a long time and I have no idea what causes the problem nor a precise method to fix it.