XPe freezes?

[Lucvdv]

I've been searching for a bug in my custom shell that could cause
random freezes, but now it seems that's not where the error is: it
must be either the hardware or XPe.

The system freezes, and some time later it continues as if nothing
happened.

After digging in my sources for weeks, I wrote a simple VB6 program
that appends the date and time and a sequence number to a text file
once every 15 seconds, and let that run in the background for 4 hours.

This is a small part of the output:

11/7/2003 12:25:00 PM 188
11/7/2003 12:25:15 PM 189
11/7/2003 12:25:30 PM 190
11/7/2003 12:25:45 PM 191
11/7/2003 12:52:58 PM 192
11/7/2003 12:53:13 PM 193
11/7/2003 12:53:28 PM 194
11/7/2003 12:53:43 PM 195
11/7/2003 12:53:58 PM 196
11/7/2003 12:54:13 PM 197

Between 12:25:45 and 12:52:58, 27 minutes of logs are missing.
The same thing happened on a second system where the test ran, but
there it was only 4 min 50 sec before it continued.

It seems questionable that it would be hardware-related, because I'm
using a standard OEM mainboards (Gigabyte) that must be in use in
hundreds or thousands of home PC's.

Could it be because no mouse and keyboard are connected, or something
similar? Some component that's missing?

The target was built with mouse and keyboard support to allow
interaction during tests, but the production version runs without.

 

[Howard Smith]

Are the graphics drivers installed correctly? or GART-AGP

I have seen this behaviour with ATI cards on occasions

 

[Wayne Taylor]

Hi

Has this ever worked?

Wayne

 

[Lucvdv]

Hi

Has this ever worked?

No.

Thanks to both for replying, but as usual, I found the problem half an
hour after posting a question on usenet: it was in my own code, but as
the test program indicated it was not in my shell.

There's also a custom hardware driver, and that's where it got stuck
in an interrupt handler.



The details, just to illustrate my stupidity

Because I have to generate an ack pulse of at least 40 microseconds at
each interrupt and there's no other way to do it but through software,
I had to use a loop in the interrupt handler using the processor's TSC
register for timing - stalling execution at exit until 40 microseconds
after the interrupt handler was entered, which shows up as an amount
of interrupt time (less than 2%) in processor statistics.

It turned out that instead of the full 64 bits of the TSC, my code was
monitoring only the lower 32, so there were frequent wraparounds - and
each wraparound created a minuscule possibility that it would lock up.
At each subsequent wraparound there was a small chance that it would
break loose again.

Fixed the driver so it uses the full 64 bits, and it's been running
for 18 hours without freezing now.
At 64 bits the wraparound occurs only so many thousand years after
power on, and that's the situation I _thought_ I had from the start.