I have a Gumstix Overo Fire COM that I have loaded with a basic linux kernel and mass storage drivers. The device is then connected to a host machine, to which it appears as a common USB storage device. It is then set up to repeatedly insert and remove its g_file_storage
module every 5 seconds, to emulate repeated manual and insertion of the device into the host. While this may sound odd, it is entirely necessary, as I want to collect mass amounts of USB messages from the driver.
This repetitive "insertion" and "removal" of the device works fine on Mac and Linux hosts, but on most Windows machines, I get a BSoD after about 10 insertions and removals. Initially, I thought perhaps it was the device's "removal policy" that was causing the problem, as described here. However, some experimentation showed that this setting had no effect; the BSoD still showed up even when the removal policy was optimized for quick removal.
Also, I get no BSoD nor any errors on some Windows machines on which I have administrator control and which have all factory/default settings. The problem mostly occurs on public machines that are set up to have higher security and restricted user settings. Therefore, I believe it is some security setting that is causing the problem, but I am not familiar enough to know what exactly.
What sort of setting could be causing this problem?
EDIT: Here is the "Technical Information" on the BSoD:
*** STOP: 0x0000007E (0xFFFFFFFFC0000005, 0xFFFFF88001612652, 0xFFFFF88002FB9308, 0xFFFFF88002FB8B60)
*** FarSpace.sys - Address FFFFF88001612652 base at FFFFF88001600000, DateStamp 50046f1f
From what I can tell, the Farspace.sys
is part of the Deep Freeze software.
A 7E stop error is "SYSTEM_THREAD_EXCEPTION_NOT_HANDLED":
This bug check indicates that a system thread generated an exception that the error handler did not catch.
I'm pretty sure FarSpace.sys is part of Faronics' software, and they make Deep Freeze. Since you say they are public machines, I'm guessing someone has them locked down with Deep Freeze, and that fact is making them not play nicely with your abnormal USB insertions/removals.
If that's the case, then first I'd test to see if they behave any differently while "thawed", and if so I'd then approach Faronics' support from some guidance on doing what you want while the PC is "frozen".
Also, you may want to quadruple check any code you're using to ensure it's cleaning up it's threads properly when done with them.
User contributions licensed under CC BY-SA 3.0