next topic »

[on:]

If I leave my Arduino UNO connected to my PC, and the PC goes to sleep, then my PC cannot resume and has the blue screen of death.  My Arduino is sending lots of stuff via Serial.Print... but I do not have to start the Serial Monitor to get the bad behaviour.

The problem is deterministic and easy to repro.
I dont need to wait - if I put the machine to sleep manually then waken it from its slumber, it will happen immediately.

Im using Windows 8

In case its relevant, here is the info from Device Manager:
Arduino UNO ( COM3)
Manufacturer : http://www.arduino.cc
Location:   Port_#0001.Hub_#0004
Driver Date 1/01/2012
Driver Version 1.0.0.0
Digital Signer: Joe's-Software-Emporium
Driver Files  c:\windows\system32\DRIVERS\usbser.sys
   File Version 6.2.9200.16384 ( win8_rtm.120725-1247)
Power Data
   Current power state:
   D0
   
   Power capabilities:
   0000005D
   PDCAP_D0_SUPPORTED
   PDCAP_D2_SUPPORTED
   PDCAP_D3_SUPPORTED
   PDCAP_WAKE_FROM_D0_SUPPORTED
   PDCAP_WAKE_FROM_D2_SUPPORTED
   
   Power state mappings:
   S0 -> D0
   S1 -> D2
   S2 -> D2
   S3 -> D2
   S4 -> D2
   S5 -> D3

[Reply #1 on:]

Have you determined that the fault occurs in usbser.sys?

[Reply #2 on:]

No, I haven't chased where exactly the problem happens.  I did try - I opened the minidump that Windows produces with Visual Studio, but didn't get far.  Turns out on this machine I only have VS2012, and it complained that the minidump could not be opened by such a new version!  So much for backwards compatibility.  I doubt I would have learnt much anyway.

[Reply #3 on:]

You can use this online tool to upload your crash dump:
http://www.osronline.com/page.cfm?name=analyze

[Reply #4 on:]

Well Im not sure what to make of it, but I submitted the minidump, and this is part of the analysis:

BUGCODE_USB_DRIVER (fe)
USB Driver bugcheck, first parameter is USB bugcheck code.
Arguments:
Arg1: 0000000000000004, IRP_URB_DOUBLE_SUBMIT The caller has submitted an irp
   that is already pending in the USB bus driver.
Arg2: fffffa800e6dd010, Address of IRP
Arg3: fffffa800b035f80, Address of URB
Arg4: fffffa8012549010

[Reply #5 on:]

No indication of which driver?

[Reply #6 on:]

hcmon.sys seemed to be implicated, I googled and found that is probably VMware, so uninstalled that, but it made no difference.
It seems that it might be usbser.sys
Here is the latest report:  http://solarsatisfaction.com.au/crashDumpReport.txt
Im after some ideas on how to get a better idea about this bug.
1. Is it likely to be the Arduino driver or Windows
    If Arduino driver, am I using the most recent one?
2. If Windows is it likely to be because Im using Windows 8?
    Ill try my laptop - it also runs Windows 8, to see if it behaves the same.
3. Could it be exacerbated by the fact the Arduino is busy spitting out characters to the port?
    Should I upload blink or comment out all the Serial.Print statements?
4. I have other USB things plugged in eg a Seagate drive I use for backups - is it worth pulling
    them out?

[Reply #7 on:]

It seems that it might be usbser.sys

Probably...

STACK_TEXT:
...usbser+0x90d6...

1. Is it likely to be the Arduino driver or Windows
    If Arduino driver, am I using the most recent one?

The Arduino "driver" is a stock driver provided by Microsoft.  It is the driver used by almost all USB serial port devices.

2. If Windows is it likely to be because Im using Windows 8?
    Ill try my laptop - it also runs Windows 8, to see if it behaves the same.

Could be.  Microsoft may have changed the driver between 7 and 8.  They certainly made a lot of other changes.

When I have some time, I'll try it with Windows 7 (I think that's what's on this computer.   )

3. Could it be exacerbated by the fact the Arduino is busy spitting out characters to the port?

It may be "exacerbated" by the constant stream but that is most certainly not the root cause.  I've worked with serial devices that transmit constantly when powered and I've never had a kernel panic because of it.

    Should I upload blink or comment out all the Serial.Print statements?

Only if you're curious or want a quick resolution.

4. I have other USB things plugged in eg a Seagate drive I use for backups - is it worth pulling
    them out?

Yes.  Kernel drivers often share IRPs with the layers above and below.  It is possible the USB HUB driver or USB PORT driver is the root cause.

[Reply #8 on:]

If the Arduino "driver" is a stock driver provided by Microsoft, I have to confess to being a little confused.   I had trouble when I first installed the Arduino IDE - Windows insisted on the drivers being signed.  So I had to use a technique described on this forum to get them installed properly.     So if that wasn't the USB driver, was it just the INF file that wasn't signed??

Anyway, I can confirm :

- I get the same problem on another machine ( but I do have similar software and configuration on both, so that's not conclusive)

- Unplugging the other USB device made no difference

- Not sending any characters from the Arduino ( ie even the blink program which doesn't use Serial at all) doesn't make the problem go away.

Do any other users get this behaviour or am I the only one ???

Where to from here?

You've all been very helpful, but if the fault lies in Microsoft code there may not be much that can be done? 

[Reply #9 on:]

...was it just the INF file that wasn't signed??

Yes.

- Not sending any characters from the Arduino ( ie even the blink program which doesn't use Serial at all) doesn't make the problem go away.

I vaguely recall that I have put a computer to sleep with an Arduino attached without any problems.  If I'm remembering correctly, that would indicate the problem is with Windows 8 (or your specific Arduino or your computers).

Do any other users get this behaviour or am I the only one ???

I'll test in a bit with Windows 7.

You've all been very helpful, but if the fault lies in Microsoft code there may not be much that can be done? 

If that is the final conclusion, I strongly encourage you to at least attempt to report the problem.  I've have mixed success reporting bugs to Microsoft but I can guarantee they will not fix it if they do not know about it.

[Reply #10 on:]

Windows 7, 64 bit.  Sleep and Hibernate worked with no problems.  After waking the computer, I would either open Serial Monitor (to see lots of random numbers) or Upload.

Note: Sleep does not power-off the board.  Hibernate does.

Ensure usbser.sys is up-to-date.