ivobauer
asked on
Any attempt to do float division by zero crashes my system
Hi all.
I've got a really weird problem. I've just bought new computer and reinstalled Windows, Delphi and a bunch of other things. While playing with my Delphi I encountered a strange behaviour which occurs only on my machine (of about five tested). To demonstrate it, simply create new project, put two TEdits and one TButton onto the Form1. Attach the following OnClick handler to the button:
procedure TForm1.Button1Click(Sender
begin
Caption := FloatToStr(StrToFloat(Edit
end;
Now run your app, enter for example value of 5 into Edit1 and zero value into Edit2. When the button is clicked, I (and probably most of you) will expect EZeroDivide to be raised and appropriate message to be shown. Nope! When I run this app on my new machine, I get a blue-screen saying that exception 0E has occured somewhere in the Windows and the system completely hangs!!! The reboot is no solution - windows will hang immediately during next startup. I have to completely turn off the computer, wait for a few seconds and then switch it on again. This happens when running from either within or outside the Delphi IDE.
I will be most honoured to see your comments asap... Please help me!
I'm running Delphi 5, Update Pack #1 on Windows 98 SE.
Best regards, Ivo.
P.S. Integer division by zero raises an exception properly as expected...
I've got a really weird problem. I've just bought new computer and reinstalled Windows, Delphi and a bunch of other things. While playing with my Delphi I encountered a strange behaviour which occurs only on my machine (of about five tested). To demonstrate it, simply create new project, put two TEdits and one TButton onto the Form1. Attach the following OnClick handler to the button:
procedure TForm1.Button1Click(Sender
begin
Caption := FloatToStr(StrToFloat(Edit
end;
Now run your app, enter for example value of 5 into Edit1 and zero value into Edit2. When the button is clicked, I (and probably most of you) will expect EZeroDivide to be raised and appropriate message to be shown. Nope! When I run this app on my new machine, I get a blue-screen saying that exception 0E has occured somewhere in the Windows and the system completely hangs!!! The reboot is no solution - windows will hang immediately during next startup. I have to completely turn off the computer, wait for a few seconds and then switch it on again. This happens when running from either within or outside the Delphi IDE.
I will be most honoured to see your comments asap... Please help me!
I'm running Delphi 5, Update Pack #1 on Windows 98 SE.
Best regards, Ivo.
P.S. Integer division by zero raises an exception properly as expected...
Well, I would say: Use XP... :-) Sorry, I could not resist. No, unfortunately I have no idea about the blue screen... :-(
P.S: What happens if you handle the exception with a try..except block? Do you get a blue screen nevertheless?
P.P.S: What is "somewhere in the windows"? Could be please post the full message here?
Well it sounds like there is a problem with the machine itself. Could be a bad CPU and/or math processor. Or perhaps some bad or not properly seated RAM. It could be a bad harddisk or bad sectors on the harddisk. Can you run Scandisk and Defrag successfully? In other words by process of elimination start checking your hardware. I suspect the RAM since you have to turn off the machine to get a successful reboot. Sometimes RAM modules will retain their charge and not completely be flushed until the systems power has been shutoff.
The Crazy One
The Crazy One
Try to use the "Pentium-safe FDIV" ({$SAFEDIVIDE ON} or {$SAFEDIVIDE OFF} switch) in the project options. This may already help.
If it does not help, set this option to off, go device manager, expand the system devices, and double-click the Numeric Coprozessor entry (may be labeled differently, but you'll figure out which one it is). In the properties there is a tab where you can choose to use software emulation. Active this, reboot Windows, and see if the problem persists.
Note: This is a workaround only, not a real solution, because it disables the FPU and thus degrades performance of floating-point operations quite a lot. But it may be helpful in locating the problem.
If it does not help, set this option to off, go device manager, expand the system devices, and double-click the Numeric Coprozessor entry (may be labeled differently, but you'll figure out which one it is). In the properties there is a tab where you can choose to use software emulation. Active this, reboot Windows, and see if the problem persists.
Note: This is a workaround only, not a real solution, because it disables the FPU and thus degrades performance of floating-point operations quite a lot. But it may be helpful in locating the problem.
ASKER
Well, thanks a lot for your quick replies, guys.
> What happens if you handle the exception with a try..except block?
I get a blue-screen whether the exception is handled or unhandled. I tried to wrap that call into try..except while between except..end was no code but exception wasn't swallowed here and I saw a blue-screen again.
> What is "somewhere in the windows"? Could be please post the full message here?
I don't remember the message body exactly since Iam not at home just now, but I'll try to reproduce it >>
===
Windows
An exception 0E has occured at address bla:bla. Press a key to return into OS or Ctrl-Alt-Del to reboot.
===
Pressing keys has no effect here. I must completely turn off my machine.
> Well it sounds like there is a problem with the machine itself
That's probably true. But this is a really new machine and I don't have problems with any other application.
Here is my config:
CPU Duron 750 (not overclocked)
RAM 128 MB SDRAM 133
20GB IBM IDE HDD, 7200RPM
NVidia GeForce2 MX200 VGA
ABit KT7A motheboard
I use Norton SystemWorks2000 and its DiskDoctor instead of Scandisk and it behaves very well on my machine.
I also tried to load default parameters in bios and switch off any enhancements that may degrade system stability but w/o success.
> Try to use the "Pentium-safe FDIV"
Unable to do so since I'm not at home right now...
Anyway, do you know about some SW using which I can test most of my hardware components for their proper operation?
Just now, I have tested the above mentioned example on next 2 PCs in my school and they run well. I'm so desperate...
Best regards, Ivo.
> What happens if you handle the exception with a try..except block?
I get a blue-screen whether the exception is handled or unhandled. I tried to wrap that call into try..except while between except..end was no code but exception wasn't swallowed here and I saw a blue-screen again.
> What is "somewhere in the windows"? Could be please post the full message here?
I don't remember the message body exactly since Iam not at home just now, but I'll try to reproduce it >>
===
Windows
An exception 0E has occured at address bla:bla. Press a key to return into OS or Ctrl-Alt-Del to reboot.
===
Pressing keys has no effect here. I must completely turn off my machine.
> Well it sounds like there is a problem with the machine itself
That's probably true. But this is a really new machine and I don't have problems with any other application.
Here is my config:
CPU Duron 750 (not overclocked)
RAM 128 MB SDRAM 133
20GB IBM IDE HDD, 7200RPM
NVidia GeForce2 MX200 VGA
ABit KT7A motheboard
I use Norton SystemWorks2000 and its DiskDoctor instead of Scandisk and it behaves very well on my machine.
I also tried to load default parameters in bios and switch off any enhancements that may degrade system stability but w/o success.
> Try to use the "Pentium-safe FDIV"
Unable to do so since I'm not at home right now...
Anyway, do you know about some SW using which I can test most of my hardware components for their proper operation?
Just now, I have tested the above mentioned example on next 2 PCs in my school and they run well. I'm so desperate...
Best regards, Ivo.
Have you tried to do another clean and fresh Windows installation? I know, you DID just reinstall Windows. Perhaps you should try again. And before installing ANY drivers, just start your little delphi blue screen app and check whether you get a blue screen again. If not, install driver after driver, then all the applications. After each installation check your delphi program again. Sounds dumb, doesn't it? Well, I go with the crazy one, it might be your RAM...
ASKER
> Have you tried to do another clean and fresh Windows installation?
I'll try it surely. But before I make this step I'd like to test my cpu & memory against the errors. Can you just give me link to (probably free) software apropriate for this task?
I'll try it surely. But before I make this step I'd like to test my cpu & memory against the errors. Can you just give me link to (probably free) software apropriate for this task?
Try swapping out your ram ..then your cpu ..then your mb..
of course this will be hard unless you have lots of hardware laying around... or have a friend that does :-)
if this does not narrow it down then it's probably software related.... I feel your pain..it would make me nervous to think that my system might have some bizzare quirk :-(
...of course WinDoze is pretty much a bizzare quirk already ;-)
of course this will be hard unless you have lots of hardware laying around... or have a friend that does :-)
if this does not narrow it down then it's probably software related.... I feel your pain..it would make me nervous to think that my system might have some bizzare quirk :-(
...of course WinDoze is pretty much a bizzare quirk already ;-)
ASKER
Hi to all, again.
Before to reinstalling a windows or plugging out the ram, cpu or vga off the motherboard I tested my system with Sisoft Sandra but it told me that everything including FPU works well.
Then I tried AwonWyss advice, so I disabled the FPU in System control panel and reboot the machine. Bang!!! After the restart I launched my "little delphi blue screen app" (nice term, Madshi) and I saw that sweet message telling me that float division by zero was performed! Then I enabled the FPU back, restarted machine and blu-screen was there again!
I'll probably visit my PC dealer to ask him for a cpu exchange. Do I need to perform any additional testing or this is enough to prove the FPU erroneous behaviour?
It's interesting that I tried to do my blue-screen app with VBA for applications which is part of MS Office but there is an exception properly handled. Can some do for me translation of my "blue-screen app" in a different language than Delphi to do some testing & send me the compiled exe? I'll be very appreciated. I let this question still open for a few days but then I'll probably accept AwonWyss comment as an answer.
Best regards, Ivo.
Before to reinstalling a windows or plugging out the ram, cpu or vga off the motherboard I tested my system with Sisoft Sandra but it told me that everything including FPU works well.
Then I tried AwonWyss advice, so I disabled the FPU in System control panel and reboot the machine. Bang!!! After the restart I launched my "little delphi blue screen app" (nice term, Madshi) and I saw that sweet message telling me that float division by zero was performed! Then I enabled the FPU back, restarted machine and blu-screen was there again!
I'll probably visit my PC dealer to ask him for a cpu exchange. Do I need to perform any additional testing or this is enough to prove the FPU erroneous behaviour?
It's interesting that I tried to do my blue-screen app with VBA for applications which is part of MS Office but there is an exception properly handled. Can some do for me translation of my "blue-screen app" in a different language than Delphi to do some testing & send me the compiled exe? I'll be very appreciated. I let this question still open for a few days but then I'll probably accept AwonWyss comment as an answer.
Best regards, Ivo.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Ivo, perhaps you could set the following before you perform the divide:
Set8087CW($133f);
This is supposed to disable floating point exceptions in the FPU, and the result of your statement should be 'INF'. If the blue screen still occurs, then this would point more towards the hardware side. If no exception, then this would lead suspicion to the ExcepProc routine that delphi installs into the application. (SysUtils and System units), or perhaps the _FpuMaskInit proc in system.pas
Russell
ASKER
AvonWyss & rllibby, I'm going to test your solutions as soon as possible. I'll give you feedback tomorrow...
Ivo
Ivo
rllibby, I'm aware of the FPU flags and positive that this will avoid the problem. However, disabling FPU exceptions brings the problem of having to test the result for error conditions "by hand". With this additional code, I believe that the divisions will be about as inefficient as if the Pentium-save FDIV is enabled, therefore only making the code more complicated.
Some information about INF, NaN etc. in the IEEE floating point numbers can be found here:
http://www.research.microsoft.com/~hollasch/cgindex/coding/ieeefloat.html
Some information about INF, NaN etc. in the IEEE floating point numbers can be found here:
http://www.research.microsoft.com/~hollasch/cgindex/coding/ieeefloat.html
ASKER
That's me again.
I've just exchanged the cpu with new one and something unexpected happened to me - the system exhibits the same weird behaviour as with my old Duron. I did a bit more research with a different pcs and discovered that this behaviour was encountered ONLY in systems with the cpu DURON/ATHLON with combination of ABit KT7A motherboard. Systems with another mainboards behaved correctly. I have now exchanged my ABit mainboard with a MicroStar one and entire problem is (hopefully forever) gone!
Sincere thanks to everyone who has participated in this thread. Could this question be deleted or should I grade someone with the points (probably AwonWyss)?
Best regards, Ivo.
I've just exchanged the cpu with new one and something unexpected happened to me - the system exhibits the same weird behaviour as with my old Duron. I did a bit more research with a different pcs and discovered that this behaviour was encountered ONLY in systems with the cpu DURON/ATHLON with combination of ABit KT7A motherboard. Systems with another mainboards behaved correctly. I have now exchanged my ABit mainboard with a MicroStar one and entire problem is (hopefully forever) gone!
Sincere thanks to everyone who has participated in this thread. Could this question be deleted or should I grade someone with the points (probably AwonWyss)?
Best regards, Ivo.
Well, I guess my information was quite accurate, especially since I also did mention the possibility of this being a configuration-dependent problem (versus a processor error). But of course its up to you to choose which was the most helpful comment for you; since there is quite some information in this Q, I don't think a deletion would be accurate.
ASKER
AvonWyss: It seems to be your comments that helped me a lot to locate the cause of my problem, thus I decided to grade you with the points. I'd like to thank also to eveyone who has tried to help me here...
Best regards, Ivo.
Best regards, Ivo.