Come debug Division con zero eccezione in Internet Explorer?

Question

Sto ospitando Internet Explorer in un'applicazione Windows. Posso scorrere verso il basso fino in fondo al documento. Quando quindi provo a scorrere indietro, ottengo un Divisione per zero eccezione:

Quando scorro usando Pagina su L'incidente sembra accadere alla chiamata a - IOleInPlaceActiveObject:TranslateAccelerator

Quando scorro usando il mouse, l'arresto si verifica durante la chiamata a

• DispatchMessage

Ad ogni modo, l'incidente sta accadendo in Internet Explorer.

Il Traccia dello stack mostrato da Delphi al momento dell'eccezione:

È diverso dalla traccia dello stack mostrata dall'eccezione di Jedi:

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

Ho provato a eseguire il debug dell'incidente in windbbg:

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)

Ma poiché Delphi cattura tutte le eccezioni, non fa mai porri e spezza WindBG. (O forse è per questo che WindBG non si rompe).

Come posso impedire a Delphi di catturare eccezioni, in modo che l'applicazione sia autorizzata a un arresto anomalo, in modo da poter ottenere le istruzioni che causano il problema. È un'eccezione in virgola mobile, in qualche luogo è il codice che sta cercando di dividere per zero.

---

Qualcun altro sta ottenendo lo stesso crollo nelle stesse circostanze:

• Divisione per zero bug in IE 9 / sulla barra di scorrimento clicca

Con gli utili suggerimenti di Microsoft che disattiva qualsiasi componente aggiuntiva di terze parti e prova a correre in modalità provvisoria.

Anche se è bello essere rivendicati che non sono l'unico a provare questo problema; Sono più interessato a una soluzione.

---

Le eccezioni possono essere mascherato Chiedendo all'unità di punta mobile di non sollevare eccezioni, armeggiando la parola di controllo del punto galleggiante con il FLDCW Istruzione:

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)
    }

Tuttavia, mi piacerebbe sapere come posso trovare il linea Questo sta lanciando l'eccezione.

Answer 1

Per ottenere la riga di codice che lancia l'eccezione, dovrai chiedere a Microsoft l'origine mshtml.dll. Ecco dove viene lanciata l'eccezione, dall'istruzione all'indirizzo 00378B89.

Potresti provare ad aprire la finestra della CPU e guardare il codice della macchina dalla DLL, ma se non ti senti già a tuo agio nel debug del codice della macchina di qualcun altro, non so quanto ti farà bene.

La traccia dello stack del debugger e lo stack JCL mi sembrano abbastanza simili. La differenza principale è che JCL cerca di fornire alcune informazioni sulla funzione DLL e il debugger no. Questa non è molta differenza, però; Le informazioni mostrate da JCL non hanno senso poiché il nome della funzione più vicino che trova è quasi un megabyte lontano dall'effettiva istruzione difettosa. L'altra differenza è se TwinControl.MainwndProc sia incluso nella traccia dello stack, che sospetto sia dovuto al fatto che la traccia dello stack sia stata determinata leggendo le informazioni sul debug DCU o analizzando il contenuto fisico dello stack.

Answer 2

Se non usi Math.SetExceptionMask([exInvalidOp, exDenormalized, exZeroDivide, exOverflow, exUnderflow, exPrecision]), troverai che la soluzione funziona solo Finestre a 64 bit.