i am hosting Internet Explorer in a Windows application. i can scroll down to the bottom of the document. When i then try to scroll back up i get a division by zero exception:
When i scroll using Page Up the crash appears to happen at the call to
– IOleInPlaceActiveObject:TranslateAccelerator
When i scroll using the mouse the crash happens during the call to
Either way, the crash is happening in Internet Explorer.
The stack trace shown by Delphi at the time of the exception:
Is different from the stack trace shown by Jedi’s exception tracing:
Exception EZeroDivide in module mshtml.dll at 00378B89.
Floating point division by zero.
Exception raised by object: TEmbeddedWB
Full Exception Details:
EZeroDivide
ExceptionCode: 0xC000008E (EXCEPTION_FLT_DIVIDE_BY_ZERO)
The thread tried to divide a floating-point value by a floating-point divisor of zero.
ExceptionFlags: 0x00000002
ExceptionAddress: 0x574C8B89
Parameters: (0x00000000)
EXCEPTION_RECORD: nil
Message: Floating point division by zero
Stack Trace:
[574C8B89] Unknown function at DllGetClassObject + $FF033
[004CA61E] OleCtrls.TOleControl.WndProc (Line 2171, "olectrls.pas" + 12) + $10
[006CF62A] EmbeddedWB.TEmbeddedWB.WBWndProc (Line 1492, "EmbeddedWB.pas" + 31) + $8
[0046200C] Forms.StdWndProc (Line 1459, "Forms.pas" + 8) + $0
[0046D2A2] Forms.TApplication.IsKeyMsg (Line 6588, "Forms.pas" + 20) + $1E
[0046D43F] Forms.TApplication.ProcessMessage (Line 6626, "Forms.pas" + 9) + $2A
[0046D4AB] Forms.TApplication.HandleMessage (Line 6649, "Forms.pas" + 1) + $6
[0046938C] Forms.TCustomForm.ShowModal (Line 4692, "Forms.pas" + 22) + $5
[007D72AD] FMain.TfrmMain.actControlPanelExecute (Line 566, "FMain.pas" + 5) + $5
[00424AF5] Classes.TBasicAction.Execute (Line 8077, "Classes.pas" + 3) + $9
[00455369] ActnList.TContainedAction.Execute + $31
[0045B6AE] Menus.TMenuItem.Click (Line 1738, "Menus.pas" + 9) + $8
[0045CD71] Menus.TMenu.DispatchCommand (Line 2446, "Menus.pas" + 5) + $5
i tried debugging the crash in WinDbg:
ModLoad: 00000000`75360000 00000000`75372000 C:\Windows\syswow64\DEVOBJ.dll
ModLoad: 00000000`71940000 00000000`719fa000 C:\Windows\SysWOW64\d2d1.dll
ModLoad: 00000000`715e0000 00000000`716ea000 C:\Windows\SysWOW64\DWrite.dll
ModLoad: 00000000`71870000 00000000`718f3000 C:\Windows\SysWOW64\dxgi.dll
ModLoad: 00000000`74fb0000 00000000`74fdd000 C:\Windows\syswow64\WINTRUST.dll
ModLoad: 00000000`71db0000 00000000`71ddc000 C:\Windows\SysWOW64\d3d10_1.dll
ModLoad: 00000000`71900000 00000000`7193a000 C:\Windows\SysWOW64\d3d10_1core.dll
ModLoad: 00000000`6e5c0000 00000000`6e6ec000 C:\Windows\SysWOW64\D3D10Warp.dll
ModLoad: 00000000`6d480000 00000000`6d63b000 C:\Windows\SysWOW64\jscript9.dll
ModLoad: 00000000`714f0000 00000000`714fb000 C:\Windows\SysWOW64\msimtf.dll
ModLoad: 00000000`6f080000 00000000`6f0ab000 C:\Windows\SysWOW64\msls31.dll
ModLoad: 00000000`082c0000 00000000`082fc000 C:\Windows\SysWOW64\Oleacc.dll
ModLoad: 00000000`613e0000 00000000`6140e000 C:\Windows\SysWOW64\MLANG.dll
ModLoad: 00000000`62bb0000 00000000`62cb2000 C:\Windows\SysWOW64\d3d10.dll
ModLoad: 00000000`62b70000 00000000`62ba3000 C:\Windows\SysWOW64\d3d10core.dll
(834.d04): Unknown exception - code c000008e (first chance)
But because Delphi catches all exceptions, it never leeks out and breaks WinDbg. (Or maybe that’s why WinDbg doesn’t break).
How can i stop Delphi from catching exceptions, so that the application is allowed to werfault crash, so i can get the instruction that’s causing the problem. It’s a floating point exception, somewhere is the code that is trying to divide by zero.
Someone else is getting the same crash in the same circumstances:
With the helpful suggestions from Microsoft that he turn off any 3rd party addons, and try running IE in safe mode.
While it’s nice to be vindicated that i’m not the only one experiencing this problem; i’m more interested in a solution.
The exceptions can be masked by asking the floating point unit not to raise exceptions, by fiddling the floating point control word with the FLDCW instruction:
procedure TfrmControlPanel.FormCreate(Sender: TObject);
begin
FSaved8087CW := Default8087CW; // Save this because Set8087CW changes it.
Set8087CW($027F); //restore later using Set8087CW(FSaved8087CW);
//$027F comes from http://msdn.microsoft.com/en-us/library/ms235300.aspx
{
Scrolling in browser was causing floating point exceptions
http://stackoverflow.com/questions/9472265/how-to-debug-division-by-zero-exception-in-internet-explorer
What it boils down to is that MS habitually compile their code with FP exceptions masked.
Embarcadero tools habitually unmask them. Thus the MS code is written assuming that FP exceptions
will not be raised and is not resilient to them. To deal with that you have to mask the exceptions
before calling into the MS code. If your app does not floating point then just mask the exceptions
at start up and be done with it. Call Set8087CW($027F) at start up and you are good to go.
Default8087CW: $1332 = 0001 0011 0011 0010
New 8087CW: $027F = 0000 0010 0111 1111
...I RCPC ..MM MMMM
Bit 0: Invalid Operation (IM) |
Bit 1: Denormal Operand (DM) |
Bit 2: Zero Divide (ZM) | Exception Masks (Bits 0..5)
Bit 3: Overflow (OM) | When one of these mask bits is set, its corresponding x87 FPU
Bit 4: Underflow (UM) | floating-point exception is blocked from being generated
Bit 5: Precision (PM) |
Bit 6: (reserved)
Bit 7: (reserved)
Bit 8: +Precision Control (PC) 00=Single Precision (24 bits), 10=Double Precision (53 bits), 11=Double Extended Precision (64 bits), 01=reserved
Bit 9: /
Bit 10: + Rounding Control (RC)
Bit 11: /
Bit 12: Infinity Control | not meaningful for anything past the 80287 math coprocessor
Bit 13: (reserved)
Bit 14: (reserved)
Bit 15: (reserved)
}
Still, i’d like to know how i can find the line that’s throwing the exception.
To get the line of code that throws the exception, you’ll have to ask Microsoft for the source to mshtml.dll. That’s where the exception is thrown, by the instruction at address 00378B89.
You could try opening the CPU window and looking at the machine code from the DLL, but if you’re not already comfortable debugging someone else’s machine code, I don’t know how much good it’ll do you.
The debugger’s stack trace and the JCL stack trace look pretty similar to me. The main difference is that the JCL tries to give some information about the DLL function and the debugger doesn’t. That’s not much difference, though; the information the JCL shows is meaningless since the nearest function name it finds is nearly a megabyte away from the actual faulting instruction. The other difference is whether TWinControl.MainWndProc is included in the stack trace, which I suspect is due to whether the stack trace was determined by reading DCU debug information or by analyzing the physical contents of the stack.