BulkUSB driver unstable on Laptop w/XP

Hello,

I am still a relative noob in the world of device drivers. I have had
some success in the past but recently I have developed a problem that I
can't find my way through.

When I started I followed the Oney recommendations and selected a sample
driver to start from. In this case I started with the sample BulkUSB
driver source from the DDK. I adjusted the necessary block/buffer sizes
to meet my device requirements and added IOCTL ID macros until I was
able to do everything I needed. I compiled it and installed on Win2k.

[and the crowd went wild]

More recently I have replaced my development machine (the win2k laptop)
with a new a new XP laptop. I am now paying for the relative ease with
which I acquired my working DD. When I plug my device in to this laptop
I frequently but not always get the BSOD! Before I enabled legacy
support in the laptop firmware I got the BSOD whenever the device was
attached...even on reboot.

I am more prone to distrust my driver's completeness than any sort of
odd hardware incompatibilities but really I don't have a basis for that
either. I am at a loss where to go from here. I am certain that before
too long someone who has one of our devices will hit this situation. I
want to solve it before that.

I have rebuilt the driver in the XP build environment of the DDK. That
initially appeared to help but then the BSOD started re-appearing.

I can provide much more information but I don't know what is relevant
and what is not. This is a simple bulkUSB device. It has 2 endpoints
(1 out, 1 in). When I don't get the BSOD everything works pretty much
the way I want it to.

Hopefully someone here has a tip that might nudge me in the right
direction.

TIA,
Kevin

Kevin
Wed Apr 20 07:23:40 CDT 2005

One important (??) additional piece of info that I just found...

I loaded up the the last memory dump in WinDbg. Once I fixed up the
symbols I found that the crash is occuring in BulkUSB_AbortPipes!

Why would it be calling AbortPipes during device arrival!?

Upon further review of that code (again this is right out of the BulkUSB
examples in the DDK) I can see where a newly arriving device might not
be ready for the calls being made in AbortPipes. So...the question may
be simply...why does this function get called as I plug IN the device?

TIA,
Kevin

Kevin wrote:
> Hello,
>
> I am still a relative noob in the world of device drivers. I have had
> some success in the past but recently I have developed a problem that I
> can't find my way through.
>
> When I started I followed the Oney recommendations and selected a sample
> driver to start from. In this case I started with the sample BulkUSB
> driver source from the DDK. I adjusted the necessary block/buffer sizes
> to meet my device requirements and added IOCTL ID macros until I was
> able to do everything I needed. I compiled it and installed on Win2k.
>
> [and the crowd went wild]
>
> More recently I have replaced my development machine (the win2k laptop)
> with a new a new XP laptop. I am now paying for the relative ease with
> which I acquired my working DD. When I plug my device in to this laptop
> I frequently but not always get the BSOD! Before I enabled legacy
> support in the laptop firmware I got the BSOD whenever the device was
> attached...even on reboot.
>
> I am more prone to distrust my driver's completeness than any sort of
> odd hardware incompatibilities but really I don't have a basis for that
> either. I am at a loss where to go from here. I am certain that before
> too long someone who has one of our devices will hit this situation. I
> want to solve it before that.
>
> I have rebuilt the driver in the XP build environment of the DDK. That
> initially appeared to help but then the BSOD started re-appearing.
>
> I can provide much more information but I don't know what is relevant
> and what is not. This is a simple bulkUSB device. It has 2 endpoints
> (1 out, 1 in). When I don't get the BSOD everything works pretty much
> the way I want it to.
>
> Hopefully someone here has a tip that might nudge me in the right
> direction.
>
> TIA,
> Kevin

Guillaume
Wed Apr 20 10:16:01 CDT 2005

Kevin wrote:
> I loaded up the the last memory dump in WinDbg. Once I fixed up the
> symbols I found that the crash is occuring in BulkUSB_AbortPipes!
>
> Why would it be calling AbortPipes during device arrival!?

In my bulkusb sample, BulkUsb_AbortPipes() is called in
HandleSurpriseRemoval() and HandleRemoveDevice(), and that's about
it.

I think you should take a look at the USB data flow if you can.
There are various software tools to do this (one of them that I use
is SnoopyPro ( http://sourceforge.net/projects/usbsnoop/ ). Works well
and it might help you figure out why a device removal or surprise
removal might happen when you plug-in your device.

- Your USB device may be faulty.
- The bulkusb sample is not quite production-quality, so that could
be that it doesn't handle very well cases where the device is faulty
and doesn't respond quite as expected during the device insertion phase.
- There may be a bug you added in the driver.

In any case, sniffing the USB data exchange could be helpful.

Kevin
Wed Apr 20 11:56:47 CDT 2005

First, thanks for the reply.

I just finished restarting after another wipe-out (BSOD). This time I
generated it from within Snoopy. The problem I have with Windows based
test processes is that they do not provide a means to see what happens
since Windows itself is falling out from under.

Since my OP I have discovered that the original BulkUSB examples have
all been redone in the more recent DDK that I just installed. I am in
the process of making the changes to it...to see if it is more likable
to Windows.

thanks again,
Kevin

Guillaume wrote:
> Kevin wrote:
>
>> I loaded up the the last memory dump in WinDbg. Once I fixed up the
>> symbols I found that the crash is occuring in BulkUSB_AbortPipes!
>>
>> Why would it be calling AbortPipes during device arrival!?
>
>
> In my bulkusb sample, BulkUsb_AbortPipes() is called in
> HandleSurpriseRemoval() and HandleRemoveDevice(), and that's about
> it.
>
> I think you should take a look at the USB data flow if you can.
> There are various software tools to do this (one of them that I use
> is SnoopyPro ( http://sourceforge.net/projects/usbsnoop/ ). Works well
> and it might help you figure out why a device removal or surprise
> removal might happen when you plug-in your device.
>
> - Your USB device may be faulty.
> - The bulkusb sample is not quite production-quality, so that could
> be that it doesn't handle very well cases where the device is faulty
> and doesn't respond quite as expected during the device insertion phase.
> - There may be a bug you added in the driver.
>
> In any case, sniffing the USB data exchange could be helpful.

Guillaume
Wed Apr 20 12:20:13 CDT 2005

Kevin wrote:
> The problem I have with Windows based
> test processes is that they do not provide a means to see what happens
> since Windows itself is falling out from under.

True...
In your case, you could comment out the calls to BulkUsb_AbortPipes(),
recompile your driver and retry. That should allow you to see what is
happening with Snoopy without Windows crashing (at least, it's worth
a try)...

> Since my OP I have discovered that the original BulkUSB examples have
> all been redone in the more recent DDK that I just installed. I am in
> the process of making the changes to it...to see if it is more likable
> to Windows.

Alright. Some issues have indeed been fixed in the latest bulkusb
sample. Be aware though, from experience, that the new one isn't Windows
98 or Me-friendly in the least. You've been warned if you ever intend
to target those OS's.

Kevin
Wed Apr 20 12:52:46 CDT 2005

Thank you for the warning. Our product is not targeted to Win98/ME for
other reasons (mostly revolving around the need to run some software as
an NT service)...but in any case Win2k/XP is the target audience.

I am subsequently happy to report that the NEW device driver that I have
just finished building is NOT exhibiting the same problems. So whatever
was wrong...was wrong in the DD code. By lifting the 100 lines of IOCTL
code out of the old driver and dropping it into the new...I'm nearly off
to the races. I have plugged/unplugged about 50 times with no BSOD so
far. Sometimes the device doesn't mount...but that is a firmware
problem I believe. And when I yank/reinsert it starts the second time.

So...for now...I'm off and running again. The new sample BulkUSB is so
much easier to understand than the old. I figured out the 'old' with
hours of study. The 'new' is clear and well organized so I can follow
what they are trying to do. All in all...a good day.

Thanks again,
Kevin

Guillaume wrote:
> Kevin wrote:
>
>> The problem I have with Windows based test processes is that they do
>> not provide a means to see what happens since Windows itself is
>> falling out from under.
>
>
> True...
> In your case, you could comment out the calls to BulkUsb_AbortPipes(),
> recompile your driver and retry. That should allow you to see what is
> happening with Snoopy without Windows crashing (at least, it's worth
> a try)...
>
>> Since my OP I have discovered that the original BulkUSB examples have
>> all been redone in the more recent DDK that I just installed. I am in
>> the process of making the changes to it...to see if it is more likable
>> to Windows.
>
>
> Alright. Some issues have indeed been fixed in the latest bulkusb
> sample. Be aware though, from experience, that the new one isn't Windows
> 98 or Me-friendly in the least. You've been warned if you ever intend
> to target those OS's.