SerialPort and the BSOD

Question

I've written some C# code that checks whether a device is present on any SerialPort by issuing a command on the port and listening for a reply. When I just set the port speed, open the port, get the serial stream and start processing, it works 100% of the time. However, some of our devices work at different speeds and I am trying to probe for a device at various speeds to autonegotiate a connection as well as detect device presence.

When I do all this in a single thread there are no problems. However, 3s timeout at ten speeds is 30s per serial port, and there may be several. Hence the desire to probe all ports concurrently.

Sometimes this works. Sometimes Vista bluescreens. When I use threads to probe all the ports simultaneously it nearly always bluescreens. When I force everything to run in one thread it never happens.

A USB-serial Prolific PL-2303 adaptor is in use with x64 drivers.

---

@Vinko - thanks for the tip on reading minidumps.

As near as I can tell, the crux of the problem is that by starting a new asynchronous I/O operation from a different thread it is possible to give a whole new meaning to overlapped I/O, inducing a race condition inside the driver. Since the driver executes in kernel mode, BLAM!

Epilogue

Except for kicking off, don't use BeginXxx outside of the callback handler and don't call BeginXxx until you've called EndXxx, because you'll induce a race condition in driver code that runs in kernel mode.

Postscript

I have found that this also applies to socket streams.

Answer 1

You can also disable "Automatic Restart" under System Properties\Advanced\Start and Recovery\Settings. Once you disable that, you can see the BSOD and look for the error message, e.g. IRQL_LESS_OR_EQUAL, by searching for that error name, you can usually narrow down to the source of the problem.

Btw, not many notebook comes with serial ports nowadays, so you must be using USB-Serial converter? If that's the case, the driver might have been an issue to start with, since most manufacturer wrote the serial port driver as virtual driver.

Answer 2

BSOD usually means buggy drivers.

What kind of HW ports do you use? I've had BSODs with SiLabs CP21xx USB to Serial converters drivers.

Answer 3

Having written Windows drivers for one of these sort of device once, my advice would be not to waste your time with WinDbg trying to prove what you already know - i.e. that the driver you're using is buggy.

If you can find a more up-to-date driver from the PL2302, then try that, but my recommendation is that if you have to use USB->Serial adaptors, the FTDI-based ones are the best. (They're not the one I wrote the drivers for, either...)

Answer 4

There are FTDI drivers that are stable under x64 vista and win7. I second the person who said to use FTDI chipsets only.

Most of the cheap serial to usb dongles at the shops near me (Toronto, Canada) seem to be FTDI chips. It's never on the box, so I buy one, and if it's good, I go buy a box full of them.

W