Blue Screen of Death Errors when Outputting Data to COM Port

[RhythmDoctor]

I have used OpenCPN for 2 years using Windows XP on my Netbook. My GPS feed comes in on COM41 at 4800 bps, and AIS targets come in COM40 at 38400 bps. Autopilot information goes out COM41 at 4800 bps. This configuration worked fine with versions 2.5 and 3.0 of O, but it causes blue screen of death errors with 3.2.0 and 3.2.2.

The configuration works for an hour or two, but at a certain point the red "ownship" icon turns grey. At this point AIS data continue to come in on COM41, but nothing comes in on COM40. The computer will continue to run as long as I don't touch anything, but if I do any manipulation of the computer, like bringing up settings or quitting out of OpenCPN, the machine immediately crashes with a "blue screen of death" error.

I have run extended overnight tests on this issue for two weeks now using different settings in order to pinpoint the problem, and I have replicated this crash repeatedly using these settings:



If I use the exact same settings except with the output on COM40 disabled, OpenCPN will run for 2 days without anything crashing. (That's the longest that I ran my tests for.) However, after running 2 days with output turned off, if I turn the COM41 output back on, the blue screen error occurs within a couple of minutes.

Do you have any suggestions? Is there any other information that you would like me to provide? I can supply minidump files if you like.

[RhythmDoctor]

Guys - I've complimented your work in the past, and I get great utility out of your program. I can't remember if I've donated before, so I just put in another donation for you. Thanks for your great work!

As for the problem described in this thread, I ran another test with the same configuration above, except I deleted the COM40 connection. In other words, OpenCPN was receiving GPS on COM41 and sending NMEA data out COM41 to the autopilot. I was wondering whether this simplification might make a difference. It did not - the blue screen of death error occurred just as it had before.

I would still appreciate any suggestions that you have for this problem. I suspect that it may show up for other people too in the future. Please let me know if there are additional tests that you would like me to try, or additional information you would like me to provide.

[HotRod]

Sounds like a driver problem.
Try locating new drivers for your comport/usb-serial, and if you are using a usb-com adapter you might want to update your chipset driver and USB driver.

It would also be helpful if you provide us with the error displayed on the BSOD screen.

[RhythmDoctor]

Originally Posted by HotRod

Sounds like a driver problem.
Try locating new drivers for your comport/usb-serial, and if you are using a usb-com adapter you might want to update your chipset driver and USB driver.

It would also be helpful if you provide us with the error displayed on the BSOD screen.

I am not using a usb-serial converter. The signal comes in via Bluetooth, so the COM port is emulated through the Toshiba Bluetooth stack. I already reinstalled my Bluetooth driver (no improvement).

I used 2.5 and 3.0 for two years, with autopilot going out, and never had this problem. It only happens under 3.2, and I believe that you guys totally rewrote the communications code because it now sends out everything (unless you filter out certain sentences). So while I don't deny that there may be driver problem, it never appeared until I started using 3.2.

Should I try downgrading to 3.0 to see if the problem goes away? I'd prefer to use the new features of 3.2, but would be willing to downgrade if the information would be useful to you. If you don't want that information, I won't bother with the temporary downgrade.

How do I capture the blue screen? It flashes for only about a second before the reboot sequence starts.

NOTE: My message above has a typo, but your software will not allow me to edit it. It should read:

If I use the exact same settings except with the output on COM41 disabled, OpenCPN will run for 2 days without anything crashing.

[bdbcat]

RhythmDoctor....

OK, it something specific to your system, since this problem is not pandemic. I have run multiple-day tests on 3.2.2 in XP with no troubles.
Lots of others do as well.

So, lets break it down.

I can see a possible crash case if the NMEA data coming in contains "non-printable" characters, which then cause a fault when these characters are echoed out. This may or may not be the root cause of your BSOD. More investigation required....

When debugging this kind of transient problem, the first step is to try to strip away everything that is not related to the problem, without eliminating the problem itself.

So, first thing to do is limit, or filter, the sentences sent out to COM41.
I see you are sending RMB, VTG, and APB.

You may try, for testing, to remove the sentence types one-by-one, testing to failure at each step, in order to determine if it is a particular sentence type that causes the crash.

You may also want to, for testing, remove the AIS input. Simplify....

If you find a sentence type that systematically causes a crash, then the thing to do is capture a recording of your NMEA stream, using the VDR PlugIn. That way we can examine the offending sentence, and perhaps reproduce the problem at will.

Awaiting results of test....
Dave

[RhythmDoctor]

Dave,

Thanks for the advice. As you can see above, I have already stripped out a lot (such as removing the AIS channel), but I will continue to do more. My preferred setup is to run two instances of OpenCPN with a UDP channel to pass data back and forth, but I've stripped all that out for purposes of testing.

First things first: I found an updated Bluetooth Stack (Toshiba v. 8.00.12 instead of 8.00.02) that was issued late last year and provides "various fixes." So I've installed that in hopes it might address the root cause.

I also activated the "Control Checksum", which for some reason was not activated before.

In the test I started last night, I also set it to only output VTG. Those are the only sentences that OpenCPN should be sending out anyway, because there is no route active (thus no RMB) and the AIS channel is removed (thus no APB). The NMEA debug window seems to agree with this. But for the sake of eliminating all possible causes, I'm filtering out RMB and APB in my current test.

I also installed and activated the VDR plugin, so I will hopefully have a log for every test I run. I'm looking forward to seeing what are the last sentences that go in/out just before the thing crashes - I hope it gets written to disk before the crash and not lost in memory buffer.

Since each test takes a whole day, and I don't make it down to the boat every day to start a new test, I'll disappear for a few days while running my tests and will report back as soon as I have something interesting to report.

Thanks again!

Rick

[RhythmDoctor]

OK, I have an update.

The Toshiba Bluetooth driver update did not fix the problem. I had a crash after updating while running OpenCPN, just like before.

After that test, I realized one significant difference between my configuration for version 3.0 and 3.2.2. Under 3.0, I had used XPort to split COM41 into two virtual ports (COM12 and COM13). However, XPort was not compatible with 3.2.0 (as described in this thread), so I set up the UDP channel to share the COM41 input with other programs using OpenCPN's internal multiplexer.

Since the incompatibility with XPort was fixed in 3.2.2 (thanks, Dave!), I decided to launch XPort again and set OpenCPN 3.2.2 to get its GPS sentences on COM12. This configuration worked! OpenCPN ran flawlessly overnight, with no crash.

So it appears that there may be an issue with outputting NMEA sentences on COM41 which causes a blue screen crash. Outputting them on COM12 does not appear to cause the blue screen crash.

As you are probably aware, OpenCPN by default cannot receive or send on COM41 or even COM40. It maxes out at COM32. I had to insert the following code at Dave's suggestion:

[Settings]
WindowsComPortMax=42

So this leaves me wondering if this setting allows receiving on COM ports above 32, but there's something in the code that breaks if OpenCPN tries to output on a COM port above 32. That would correspond perfectly with the behavior that I am seeing. (Perhaps those sorts of problems are the reason you guys set the default maximum at COM32.)

Would someone be willing to set up hardware with a COM port (virtual, Bluetooth, whatever) above 32 and try transmitting on it? Maybe then you might duplicate the behavior that I am seeing.

Thanks,

Rick

PS - Meanwhile, I am rerunning my test with XPort, but have turned on the COM40 AIS channel as well as the UDP port. Since the stripped down version did not crash, it's time to load on all the bells and whistles and see if it's still stable. However, the purpose of the UDP port is to share data with a second instance of OpenCPN running at a different zoom level. I was unfortunately unable to get 3.2.2 to run a second instance, as described in this thread.

[CarCode]

Hint:
Do not use any other Bluetooth stack than the Microsoft Bluetooth stack comming with the OS. It is far better now than MS first attemps to support Bluetooth and works with any Bluetooth device. Toshiba always start with COM40 and the stack is buggy.
Gerhard

[RhythmDoctor]

Originally Posted by CarCode

Hint:
Do not use any other Bluetooth stack than the Microsoft Bluetooth stack comming with the OS. It is far better now than MS first attemps to support Bluetooth and works with any Bluetooth device. Toshiba always start with COM40 and the stack is buggy.
Gerhard

When I originally set up my Bluetooth nav system in 2011, I spent over a month trying to get the Microsoft stack to work. I could not get it to successfully emulate a COM port. At the time the recommendation was the exact opposite of yours - do not use Microsoft stack, use either Toshiba or BlueSoleil. BlueSoleil was not compatible with my Netbook's internal bluetooth chip, so I tried four different versions of Toshiba's stack (version 5, 6, 7, 8) and found version 8 to be by far the most reliable.

Are you telling me that Microsoft has improved their Bluetooth support for XP, or just for Windows 7 or 8? My Netbook is not capable of running Windows 7 or 8, so this is a critical issue.

If Microsoft does have an improved stack that runs under XP 32 bit, please post a link here so I can go try it.

[CarCode]

Getting the latest MS updates for XP the Microsoft Bluetooth works OK.
However once another stack is installed it might be difficult to revival the MS stack. Search with Google for this procedure.

[bdbcat]

RhythmDoctor....

I think you may be onto something here regarding BT stack issues on XP.

The more I think about this, the less likely it is that OCPN can cause Blue Screen. Faults in a driver (system space, Ring1)will cause Blue Screen, usually, while faults in OCPN (user space, Ring 3) cause a controlled "Application has crashed..." dialog from Windows. Usually...

I think the COM number above 32 is not related to the crash. From the perspective of OCPN, it is just an opaque handle. The number 32 was arbitrarilly chosen by us to minimize the amount of time necessary for OCPN to enumerate serial ports.

So, the question is:
"Why does OCPN cause the Toshiba stack to crash, while XPort does not? Hmmmm?"

Dave

[RhythmDoctor]

Originally Posted by bdbcat

...So, the question is:
"Why does OCPN cause the Toshiba stack to crash, while XPort does not? Hmmmm?".

Yes, that is EXACTLY the question on my mind.

If you think of an answer, or additional tests I can do to diagnose, please let me know.

I remember what a pain it was to originally remove the Microsoft Bluetooth stack and replace it with Toshiba (it was ultimately worth it IMO). I don't look forward to removing Toshiba and going back to Microsoft, especially if the experience is as bad as it was before, because I'll just have to undo it all and go back to Toshiba again. It's enough to make me pull out another hard drive to do the experiment, so I can just swap the drive back if I need to.

I'm not going to mess with Bluetooth drivers until I've tried other things first - I just don't want to go there if I don't have to. I'm going to keep testing with XPort and try to get portable mode working.

Let me know if you have any ideas.

[barnakiel]

A quick, side, but related, question:

If I forward some NMEA data to say COM X and this happens to be where our BT is plugged in (an external USB BT dongle) - will the BT dongle transmit this data?

Asking because I can transmit TCP data over wifi BUT I know that BT is a fraction of energy consumed.

barnakiel

[RhythmDoctor]

Originally Posted by RhythmDoctor

...Meanwhile, I am rerunning my test with XPort, but have turned on the COM40 AIS channel as well as the UDP port. Since the stripped down version did not crash, it's time to load on all the bells and whistles and see if it's still stable. However, the purpose of the UDP port is to share data with a second instance of OpenCPN running at a different zoom level. I was unfortunately unable to get 3.2.2 to run a second instance, as described in this thread.

Here's an update on my latest test.

I ran OpenCPN 3.2.2 again with XPort sending GPS data on COM12. I also set it up to receive AIS data on COM40. I turned on the output of COM12 to send data (VTG, RMB, APB) to autopilot. I also activated a route so that there would be RMB sentences going out. Since I do not have portable mode configured yet, I could not launch a second instance of OpenCPN. But other than that, this is the full set of features that I typically use.

Once again, there was no blue screen crash in this overnight test, as long as I was using XPort to move all the COM41 communications to COM12.

I have also taken some time to investigate the possibility of removing my Toshiba Bluetooth stack and replacing it with Microsoft. As I was doing this, I started to remember some of the problems I encountered with Microsoft's stack. As I recall, I could only establish half-duplex virtual COM ports using the Microsoft stack. It did not seem to support full-duplex virtual COM ports. While I could do what I need to with three half-duplex Bluetooth connections, that would require three separate serial-bluetooth adapters, and I only have two. So I need one of the adapters to be full duplex. Since I receive AIS data in at 38400 gps (on COM41), receive GPS data in at 4800 bps, and send autopilot data out at 4800 bps, it makes sense to make the two 4800 bps connections on a full-duplex 4800 bps Bluetooth connection. The Toshiba version 8 stack did this flawlessly (until this latest blue screen problem), and that's why I chose it over Microsoft's stack.

My MSI Wind netbook came with Toshiba stack v5 pre-installed by default, and I tested v6, 7, and 8 (in addition to the Microsoft stack) before determining that Toshiba v8 was most reliable. All this testing took over a month in early 2011. Since then, Toshiba has come out with their Bluetooth stack v9, but I have not tried it.

[bdbcat]

RhythmDoctor....

OK, tested XP with MS Bluetooth stack using Broadcom dongle, pairing to a Holux GPS receiver.

Works fine for input. I could not verify that output is actually working, since there is only the Holux receiver on the line. It at least does not crash with MS stack.

Tried to install Toshiba 8.00.03 stack, but failed. Could not get MS stack to let go of the hardware. Toshiba stack might not be compatible with my dongle. Yada/yada... Any tips/hints?

Until I can get the Toshiba stack running, I'm afraid there is not much I can do to debug this BSOD.

Meanwhile, for your scenario, is there any problem with using the XPort solution until we sort this out?

Dave