Windows Reset Without BugCheck

Hi All,

I have a driver using COM port internally. I need accurate read timing so I
am reading bytes one by one.
I start with reading a single byte and on read completion I am sending
another request for the next byte.
The flow of execution is so that if there are a few bytes pending every read
will complete immediately before function return, like this:

Two Single Bytes:
Read (1)
Read (1) Completion invoked
- Read (2)
Read (1) Completion done
Read (2) Completion invoked
- Read (3)
Read (2) Completion done

Multiple Bytes pending:
Read (1)
Read (1) Completion invoked
- Read (2)
- Read (2) Completion invoked
- Read (3)
- - Read (3) Completion invoked
- - - Read (4)
- - - Read (4) Completion invoked
- - - - Read (5)
- - - Read (4) Completion done
- - Read (3) Completion done
- Read (2) Completion done
Read (1) Completion done

When I have about 30 bytes pending the system will reset / hang. I'm using
Virtual PC with Windows XP SP2.

Any solution / design methodology are welcome.

TIA,
Asaf

> I have a driver using COM port internally. I need accurate read timing

Why _ever_ there is a need for such a strange thing?

First of all, COM port - if used in a mainstream normal mode of modem or null-modem connection - just plain does not support accurate timing.

In MS-DOS era, there were some hardware+software products which _require accurate timing_ over a COM port, but this is more or less a perversion which is nearly impossible to implement in Windows.

And even in this case, you only need timings on writes you issue, to satisfy the device which requires them.

> When I have about 30 bytes pending the system will reset / hang.

What does it mean "reset"? crashed? have you ever disabled automatic reboot on crash in Control Panel/System? what about memory dumps analyzis?

Hang? can you connect a debugger to it? can you use CrashOnCtrlScroll to make a memory dump of this hang?

Also note that accurate timings on the COM port in _Virtual PC_ is a boring and failed joke. :-) the virtualization will spoil the timings to a degree so major that your efforts are useless.

--
Maxim S. Shatskih
Windows DDK MVP

http://www.storagecraft.com

Just off top of my head... try VMware Workstation.
It also has a nice replay feature and other goodies fore debugging, though
I'm not sure how exactly to apply them for your situation.
Do you forward requests to serial.sys or acess the registers directly?
-- pa


"Asaf Shelly" <> wrote in message
newsA949373-32BC-4DC5-80E0-...
> Hi All,
>
> I have a driver using COM port internally. I need accurate read timing so
> I
> am reading bytes one by one.
> I start with reading a single byte and on read completion I am sending
> another request for the next byte.
> The flow of execution is so that if there are a few bytes pending every
> read
> will complete immediately before function return, like this:
>
> Two Single Bytes:
> Read (1)
> Read (1) Completion invoked
> - Read (2)
> Read (1) Completion done
> Read (2) Completion invoked
> - Read (3)
> Read (2) Completion done
>
> Multiple Bytes pending:
> Read (1)
> Read (1) Completion invoked
> - Read (2)
> - Read (2) Completion invoked
> - Read (3)
> - - Read (3) Completion invoked
> - - - Read (4)
> - - - Read (4) Completion invoked
> - - - - Read (5)
> - - - Read (4) Completion done
> - - Read (3) Completion done
> - Read (2) Completion done
> Read (1) Completion done
>
> When I have about 30 bytes pending the system will reset / hang. I'm using
> Virtual PC with Windows XP SP2.
>
> Any solution / design methodology are welcome.
>
> TIA,
> Asaf

"Maxim S. Shatskih" wrote:

> > I have a driver using COM port internally. I need accurate read timing
>
> Why _ever_ there is a need for such a strange thing?

A communication frame can end by silent period.

>
> First of all, COM port - if used in a mainstream normal mode of modem or null-modem connection - just plain does not support accurate timing.
>

Only need timing difference between bytes. The real system usually uses a
dedicated hardware (RS422 etc.)

> In MS-DOS era, there were some hardware+software products which _require accurate timing_ over a COM port, but this is more or less a perversion which is nearly impossible to implement in Windows.
>
> And even in this case, you only need timings on writes you issue, to satisfy the device which requires them.
>
> > When I have about 30 bytes pending the system will reset / hang.
>
> What does it mean "reset"? crashed? have you ever disabled automatic reboot on crash in Control Panel/System? what about memory dumps analyzis?
>
> Hang? can you connect a debugger to it? can you use CrashOnCtrlScroll to make a memory dump of this hang?

Sometimes the system does nothing, sometimes Virtual PC pops up a message
that says that the CPU entered an undefined state 'click here to reset'. I'm
assuming that CrashOnCtrlScroll will not work because the system is dead and
CrashOnCtrlScroll is low irql only. Also not sure how to debug it because I
am tesing it on multiple COM ports and I killed serial...

>
> Also note that accurate timings on the COM port in _Virtual PC_ is a boring and failed joke. :-) the virtualization will spoil the timings to a degree so major that your efforts are useless.
>

As long as it works, I can deploy it to a real system

Thanks,
Asaf

"Pavel A." wrote:
> Do you forward requests to serial.sys or acess the registers directly?

I am using "DosDevices\COM1" because I have to support hardware
implementations different than on-board RS232

It sounds to me like a stack overflow or flooded queue

Asaf

Never mind that.
The solution was to have read-completion queue a DPC which will issue the
next read.

Asaf

> A communication frame can end by silent period.

Send an end-of-talk marker instead.

The normal, logical and well-supported COM port use is that only _bits within a byte_ have the guaranteed timing (baud rate), and no timings between _any two_ bytes are guaranteed.

I do not say other uses are not possible, but they are _very much problematic_, especially in a multitasking OSes.

> As long as it works, I can deploy it to a real system

I have doubts you can even debug such realtime hardware-oriented code on a VM.

--
Maxim S. Shatskih
Windows DDK MVP

http://www.storagecraft.com

"Maxim S. Shatskih" wrote:

> > A communication frame can end by silent period.
>
> Send an end-of-talk marker instead.

Can't. I am supporting an existing embedded system.

>
> The normal, logical and well-supported COM port use is that only _bits within a byte_ have the guaranteed timing (baud rate), and no timings between _any two_ bytes are guaranteed.
>
> I do not say other uses are not possible, but they are _very much problematic_, especially in a multitasking OSes.

These are embedded systems with a closed system desing. We are adding a PC
as management. No need to microseconds, only miliseconds.

>
> > As long as it works, I can deploy it to a real system
>
> I have doubts you can even debug such realtime hardware-oriented code on a VM.
>

The idea is to debug the business logic. After I find no more problems I
will start using the real HW

Asaf