I have a question regarding the way Lazarus/Fpc programs are running on windows:

A few days ago I was testing GPS communications to retrieve accurate time. I had written a small program that connected to the GPS using the SdpoSerial component.
All was working OK.

Then I decided to check how the time would differ by starting two instances of my program but due to a shortcircuit in my head I started a completely *different* program that used a different baudrate and had different handling of received data. So the program opened the port at 38200 baud but the GPS sent data at 4800 baud. It also uses the SdpoSerial component.

SURPRISE:
When I opened the port it took less than 2-3 seconds before I had bluescreened my Win7 x64 computer!

And to top it off, after Win7 recovered I *repeated* the stupid mistake and bluescreened again before I realized my mistake.

My question here though is:
How can a user level program do this?
I would have expected an access violation that would have thrown out the program but not a repeatable bluescreen.

The main difference between the two programs is that the mistakenly started program uses a not yet ready buffer class where a dynamically sized byte array is used as a buffer and data are moved using the Move function.

In all of my programming with Delphi I have never managed to make a programming error that consistently bluescreens the PC.

Bo Berglund wrote

My question here though is: How can a user level program do this? I would have expected an access violation that would have thrown out the program but not a repeatable bluescreen.

Why not ?
It can invoke a hardware driver function, and that can cause the blue screen.

The program itself is probably not the cause, but the hardware driver. By their very nature, they are less "checked" by windows.

In all of my programming with Delphi I have never managed to make a programming error that consistently bluescreens the PC.

I can reliably do this with wireless connections on my laptop. Just start the wireless, and then open mozilla firefox or IE. BS guaranteed.

Michael.

So it could be the Prolific USB-to-Serial driver then maybe? For example if the port is opened at one baudrate bu the source sends a lot of data at a much lower baudrate?

Bo Berglund wrote

So it could be the Prolific USB-to-Serial driver then maybe? For example if the port is opened at one baudrate bu the source sends a lot of data at a much lower baudrate?

It is hard to guess, but the blue screen itself typically provides the information about the nature of fault and the driver which caused it, if any. If you go further and enable creation of memory dump via control panel, that dump is usually sufficient to track the problem to its roots.

Sergei

At the time the bluescreen text said it created a dump and log, I think. But I have no idea where such would be located...

Bo Berglund ?????:

Don't know exactly about Windows 7, but in XP a full dump (memory.dmp) would be located in the Windows directory, and minidumps are written to 'minidump' subdirectory. The information can also be found in event log ('Windows was restored after critcal error ...')

Sergei

So it could be the Prolific USB-to-Serial driver then maybe?

Very likely :-(

BTW, is that a MS-certified driver?

For example if the port is opened at one baudrate bu the source sends a lot of data at a much lower baudrate?

Most probably the driver has not been tested for proper handling of framing errors.

DoDi

I think so, in fact Windows Update found a Prolific driver by itself. But it turned out to be real bad and then I searcehd the web and found a download on Prolific's website that solved all obvious problems I had with the prevcious one. So far it has worked seemingly perfect (until the BSOD that is).

OK.

Bo Berglund wrote

At the time the bluescreen text said it created a dump and log, I think. But I have no idea where such would be located...

mickey mous^H^H^H^H^H^H^H^H^H^Hicrosoft has pages for the software needed to diagnose the dumps and logs... i've been using them for a while to try to track down a BS problem on a x64 box we have in our stables... no luck yet and we've been tracking the problem for 3 years now :? :(

that would seem to indicate that the driver code has not proliferated from the manufacturer to m$ or other OEM providers so that the old stuff is properly updated...

then, it appears that you might have found another bug that they may or may not know about ;)

And right now I am reluctant to test it since my PC will die...