Blue screen and Divide by zero exceptions
Wolfgang Lindner
we have encountered problems with catching divide by zero floating point
exceptions
using delphi5.01.
On more than one machine these exceptions result in a bluescreen
(errorcode 0e) and termination of
the process, mostly. Eg. a PIII 700 standard pc, with windows98 se.
Any advice?
Thanks,
Wolfgang Lindner.
Stefan Hoffmeister
Go to
and download both the Borland Delphi 5 and the Microsoft VC++ version of
a test application. There are binaries, and, in case you are as paranoid
as I am, the complete source code for both.
Run both applications on the target systems, and please report back the
following details
* Object Pascal version crash/no crash?
* C++ version crash/no crash?
* Exact Windows version
* Exact text of any error message that comes up, including
all addresses
* Exact name and brand of the motherboard (mainboard) used
in the system
* Exact BIOS version (including date) used
--
"Sorry, but I am clueless" (sm)
NNQ - Quoting Style in Newsgroup Postings
http://web.infoave.net/~dcalhoun/nnq/nquote.html
Wolfgang Lindner
1) both versions of the test applications did crash with blue screen:
Exception 0E at address: 0028:C0059C8D
delphi masked did not crash:
FPU exceptions are masked now
Using a run count of 1000
Running EnumResources (Windows API) tests...
Number of exceptions hit: 0
------------------
Running floating point division by zero tests...
Number of exceptions hit: 0
------------------
Running floating point overflow tests...
Number of exceptions hit: 0
Done.
2)OperatingSystem: Windows 98 A Version 4.10 (Build 2222)
Processor: Intel 80686-Prozessor (586) Modell 8 Stepping 3
TotalPhysMemory: 133632000
DLL Versions:
FPUEHTEST.EXE - FPU exception handling tester - Version 1.0.0.0 - PID
4294937489 - Pfad C:\FPU\
ADVAPI32.DLL - Win32 ADVAPI32 core component - Version 4.80.1675 - Pfad
C:\WINDOWS\SYSTEM\
COMCTL32.DLL - Common Controls Library - Version 5.80 - Pfad
C:\WINDOWS\SYSTEM\
FPUEHTEST.EXE - FPU exception handling tester - Version 1.0.0.0 - Pfad
C:\FPU\
GDI32.DLL - Win32 GDI core component - Version 4.10.1998 - Pfad
C:\WINDOWS\SYSTEM\
KERNEL32.DLL - Kernkomponente des Win32-Kernel - Version 4.10.2222 - Pfad
C:\WINDOWS\SYSTEM\
OLE32.DLL - Microsoft OLE for Windows and Windows NT - Version 4.71.2900 -
Pfad C:\WINDOWS\SYSTEM\
OLEAUT32.DLL - Microsoft OLE 2.40 for Windows NT(TM) and Windows 95(TM)
Operating Systems - Version 2.40.4275 - Pfad C:\WINDOWS\SYSTEM\
USER32.DLL - Win32 USER32 core component - Version 4.10.2222 - Pfad
C:\WINDOWS\SYSTEM\
TEST.EXE - FPU exception handling test - Version 1, 0, 0, 1 - PID 4294887613
- Pfad \\ETNA\TEMPPUB\FPU\
ADVAPI32.DLL - Win32 ADVAPI32 core component - Version 4.80.1675 - Pfad
C:\WINDOWS\SYSTEM\
COMCTL32.DLL - Common Controls Library - Version 5.80 - Pfad
C:\WINDOWS\SYSTEM\
COMDLG32.DLL - Common Dialogs DLL - Version 4.72.3510.2300 - Pfad
C:\WINDOWS\SYSTEM\
GDI32.DLL - Win32 GDI core component - Version 4.10.1998 - Pfad
C:\WINDOWS\SYSTEM\
KERNEL32.DLL - Kernkomponente des Win32-Kernel - Version 4.10.2222 - Pfad
C:\WINDOWS\SYSTEM\
SHELL32.DLL - Allgemeine Windows-Shell-DLL - Version 4.72.3612.1700 - Pfad
C:\WINDOWS\SYSTEM\
SHLWAPI.DLL - Shell Light-weight Utility Library - Version 5.00.2614.3500
- Pfad C:\WINDOWS\SYSTEM\
TEST.EXE - FPU exception handling test - Version 1, 0, 0, 1 - Pfad
\\ETNA\TEMPPUB\FPU\
USER32.DLL - Win32 USER32 core component - Version 4.10.2222 - Pfad
C:\WINDOWS\SYSTEM\
WINSPOOL.DRV - Win32 WINSPOOL core component - Version 4.10.1998 - Pfad
C:\WINDOWS\SYSTEM\
3) Motherboard: ?
4) BIOS: Award Modular Bios v4.51PG =06/19/2000-693-596-W977-2A6LGH2AC-00
5) Overflow exceptions have the same effect on this machine
6) Using Windows 95C on the same computer floating point exceptions do not
result in
blue screens but in a whole string of other serious errors: repeated access
violations, external exceptions 0 and 202,
dao-Errors (not current record / unspecified dao error)
7) if coprocessor usage is turned off, operation is normal.
Stefan Hoffmeister schrieb:
Stefan Hoffmeister
>I refer to one machine, only:
That's fine. Should be representative.
>3) Motherboard: ?
That's actually a pretty crucial piece of information. Actually the
chipset (Intel / VIA / SiS / ALI) that is being used is really, really
interesting.
If I was allowed to bet...
>5) Overflow exceptions have the same effect on this machine
No surprise. Any floating point exception will have the same, disastrous
effects - no matter which compiler (Microsoft C++, Borland Delphi,
Borland C++Builder, or even a plain assembler) is used.
>6) Using Windows 95C on the same computer floating point exceptions do not
>result in
>blue screens but in a whole string of other serious errors: repeated access
>violations, external exceptions 0 and 202,
>dao-Errors (not current record / unspecified dao error)
Interesting. The data I have seen seemed to have indicated that all
versions of Windows 95 are safe from this kind of behaviour.
>7) if coprocessor usage is turned off, operation is normal.
Try running the tests a couple of times under your Windows 98
installation, with FPU "support" turned off. It *seems* as if with the
FPU (driver) turned off affected systems gets a tad bit stabler, but not
100% stable.
Do you have a chance to run Windows NT4 SP6a and Windows 2000 SP2 on the
exact same hardware?
Ok, time for me to give up some details, I guess.
************** DISCLAIMER **************
The following is based on incomplete and
possibly incorrect information. The
conclusions drawn from this information
may, or may not, be accurate.
************** DISCLAIMER **************
The combination of
* VIA chipsets
* fast CPUs (Intel 700+ Mhz, AMD 650+ Mhz)
and
* Windows 98 (first release or SE), Windows ME
with
* floating point exceptions followed by the only sane action
to follow after such an exception, namely
* an FPU reset
seems to be rather very deadly on some motherboards (!). BIOS (version /
setting) changes seem to have an improving influence, turning off the
FPU support in the device manager tends to have an improving influence,
the latest VIA 4-in-1 drivers seem to have an improving influence.
But no individual improvement, or all individual improvements combined,
seem to make the system 100% stable.
There have been the odd report that Windows 2000 SP1 is affected, too -
just start reading the thread
From: "Roger" <rj...@netzero.com>
Newsgroups: borland.public.delphi.non-technical
Subject: Request For Volunteers
Date: Fri, 13 Apr 2001 23:19:01 -0500
Message-ID: <3ad7c1d1_1@dnews>
I have a collection of additional reports in my email inbox, all
following the same, recurring theme: VIA chipset, Windows 98, floating
point exception -> FPU reset: BOOOOM.
I have no idea how wide-spread the problem is. Some motherboards with
VIA chipsets seem to be unaffected, other with the exact same chipset -
boooom. Is it the motherboard revision? The chipset revision? BIOS
programming? No idea.
Have a look at
http://www.google.com/search?q=C0059C8D
and
http://groups.google.com/groups?q=C0059C8D
and you will see some Real Fun, with no resolution.
The only advice that may actually help is
a) Avoid floating point exceptions like the plague
(You may want to mask some if you cannot avoid them)
b) Throw away the motherboard and try a different one.
Will this advice work for you? No idea.
Bad news, I know. Don't shoot the messenger.
John Herbster
> ...
> *** DISCLAIMER ***
> ...
Stefan, Thank you for the feedback. Regards, JohnH
Paul Baker
If you are allowing a division by zero to occur in a multi-threaded
application, the exception triggered by the CPU may not be handled correctly
by Windows 9x. It may be be raised in another thread at a later time. This
is not solely due to the FPU exception mask, it appears to be a bug in
Windows 9x. I have seen it frequently seen on Windows 9x and never on
Windows NT/2000. One sympton I have seen on certain systems is indeed a
Fatal Exception 0E. You are not crazy, Microsoft is. Therefore, I would
avoid allowing any floating point exceptions to occur in a multi-threaded
application that must run on Windows 9x (eg. don't divide by zero!). That
solved the problem for me.
Paul :)
"Wolfgang Lindner" <W.Li...@Market-Maker.de> wrote in message
news:3B0921A4...@Market-Maker.de...
Stefan Hoffmeister
>If you are allowing a division by zero to occur in a multi-threaded
>application, the exception triggered by the CPU may not be handled correctly
>by Windows 9x.
Go to
download the (more than trivial) source code, notice that all this is
single-threaded.
Ed Dressel
Could you give us a hint as to what chipsets cause this problem?
Thanks
Ed Dressel
Barry Kelly
"Ed Dressel" <Dressel@Bigfoot_NOSPAM_.com> wrote in message
news:3b09dd10$1_2@dnews...
> > If I was allowed to bet...
>
> Could you give us a hint as to what chipsets cause this problem?
VIA. Read the whole message, particularly the bit after the 'DISCLAIMER'.
Wolfgang Lindner
we have two machines:
1) intel pentium III700 with VIA apollo pro 133 chipset, mainboard of
'spacewalker'
2) compaq pressario with AMD Athlon800, and a VIA Chipset.
on the first machine with
Windows95, serious errors
Windows98se, bluescreen
WindowsMe, bluesscreen exception: 0E : 0028 : C00587C9
WindowsNT, ok
Windows2000, ok
on the second machine
bluescreen with windows98se
may I ask: why does delphi by itself work on these machines?
Stefan Hoffmeister schrieb:
Stefan Hoffmeister
>may I ask: why does delphi by itself work on these machines?
Because the Delphi IDE does not throw floating point exceptions.
If you look at http://groups.google.com/groups?q=C0059C8D you will
notice that floating-point intensive applications are affected, e.g.
Corel Draw, Microsoft Flight Simulator, a CD ripper, sound cards...
There is something peculiar about the way the VIA chipsets (or chipset
revisions) seem to handle floating point exceptions. And Windows
Playstation (95, 98, 98SE, ME) really, really does not like that. It's
not a Borland Delphi problem, it's not a Microsoft Visual C++ problem,
it's not an assembler problem.
It is either a generic Microsoft Windows Playstation problem or a VIA
driver problem, or a BIOS problem, or a hardware problem.
You (realistically) have zero influence on any of these, except if you
have excellent contacts to VIA/Cyrix.
Wolfgang, please do not force me through all the 117 lines of my
original reply for nothing (hence wasting my time). See
NNQ - Quoting Style in Newsgroup Postings
http://web.infoave.net/~dcalhoun/nnq/nquote.html
and
http://www.borland.com/newsgroups/netiquette.html
for details.
Thanks in advance for the future.