VISTA exception handling ??

[Ficko]

Hello guys!

This thing is bothering me for a while may somebody from the experts can shed some light on it. :P

I used to catch or rise exceptions previous from VISTA from all part of an application.
Since I switched programs stopped working. :(

Looking into it I saw that exceptions genarated in "WndProc" got kind of "mishandled" by the system not swallowed but also not followed up.

Here is an sample:

Code Select Expand


  include \masm32\include\masm32rt.inc
        WinMain PROTO :DWORD,:DWORD,:DWORD,:DWORD
        WndProc PROTO :DWORD,:DWORD,:DWORD,:DWORD
        TopXY PROTO   :DWORD,:DWORD
    .data
        szDisplayName db "Generic",0
        CommandLine   dd 0
        hWnd          dd 0
        hInstance     dd 0
    .code
start:
    invoke GetModuleHandle, NULL
    mov hInstance, eax
    invoke GetCommandLine
    mov CommandLine, eax
    invoke WinMain,hInstance,NULL,CommandLine,SW_SHOWDEFAULT
    invoke ExitProcess,eax
WinMain proc hInst     :DWORD,
             hPrevInst :DWORD,
             CmdLine   :DWORD,
             CmdShow   :DWORD
        LOCAL wc   :WNDCLASSEX
        LOCAL msg  :MSG
        LOCAL Wwd  :DWORD
        LOCAL Wht  :DWORD
        LOCAL Wtx  :DWORD
        LOCAL Wty  :DWORD
        szText szClassName,"Generic_Class"
        ;==================================================
        ; Fill WNDCLASSEX structure with required variables
        ;==================================================
        mov wc.cbSize,         sizeof WNDCLASSEX
        mov wc.style,          CS_HREDRAW or CS_VREDRAW or CS_BYTEALIGNWINDOW
        mov wc.lpfnWndProc,    offset WndProc      ; address of WndProc
        mov wc.cbClsExtra,     NULL
        mov wc.cbWndExtra,     NULL
        m2m wc.hInstance,      hInst               ; instance handle
        mov wc.hbrBackground,  COLOR_BTNFACE+1     ; system color
        mov wc.lpszMenuName,   NULL
        mov wc.lpszClassName,  offset szClassName  ; window class name
          invoke LoadIcon,hInst,500    ; icon ID   ; resource icon
        mov wc.hIcon,          eax
          invoke LoadCursor,NULL,IDC_ARROW         ; system cursor
        mov wc.hCursor,        eax
        mov wc.hIconSm,        0
        invoke RegisterClassEx, ADDR wc     ; register the window class
        mov Wwd, 500
        mov Wht, 350
        invoke GetSystemMetrics,SM_CXSCREEN ; get screen width in pixels
        invoke TopXY,Wwd,eax
        mov Wtx, eax
        invoke GetSystemMetrics,SM_CYSCREEN ; get screen height in pixels
        invoke TopXY,Wht,eax
        mov Wty, eax
         invoke CreateWindowEx,WS_EX_OVERLAPPEDWINDOW,ADDR szClassName,ADDR szDisplayName,WS_OVERLAPPEDWINDOW,Wtx,Wty,Wwd,Wht,NULL,NULL,hInst,NULL
        mov   hWnd,eax
         invoke ShowWindow,hWnd,SW_SHOWNORMAL      ; display the window
        invoke UpdateWindow,hWnd                  ; update the display
    StartLoop:
      invoke GetMessage,ADDR msg,NULL,0,0         ; get each message
      cmp eax, 0                                  ; exit if GetMessage()
      je ExitLoop                                 ; returns zero
      invoke TranslateMessage, ADDR msg           ; translate it
      invoke DispatchMessage,  ADDR msg           ; send it to message proc
      jmp StartLoop
    ExitLoop:
      return msg.wParam
WinMain endp
; #########################################################################
WndProc proc hWin   :DWORD,
             uMsg   :DWORD,
             wParam :DWORD,
             lParam :DWORD
    .if uMsg == WM_COMMAND
        .if wParam == 1000
            invoke SendMessage,hWin,WM_SYSCOMMAND,SC_CLOSE,NULL
         .endif
    .elseif uMsg == WM_PAINT
    xor eax, eax
    div al ;cause exception
    .elseif uMsg == WM_DESTROY
        invoke PostQuitMessage,NULL
        return 0
    .endif
    invoke DefWindowProc,hWin,uMsg,wParam,lParam
    ret
WndProc endp
; ########################################################################
TopXY proc wDim:DWORD, sDim:DWORD
    shr sDim, 1
    shr wDim, 1
    mov eax, wDim
    sub sDim, eax
    return sDim
TopXY endp
end start


An exception is generated in "WM_PAINT" but running it on VISTA nothing happens seemingly. :dazzled:
By debugging it looks the message loop got continuing but also couple of things are gotten screwed up as well so prg behaves strange sometimes but not terminates like it should - on win2000/xp -

Any idea why this happens and what should be the right way to rise exceptions in a message loop on VISTA?

Thanks,
Ficko

[Astro]

    xor eax, eax
    div al

You are attempting to divide by zero...

so prg behaves strange sometimes but not terminates like it should

...but I think deliberately?

I'm guessing you debugged this to death to see why?

What configuration is Vista in? UAC, DEP, etc..?

Best regards,
Astro.

[Slugsnack]

well i assembled and ran it on my machine which is running windows 7 RTM and the application did crash. something you could do if you want to handle exceptions yourself is to use SEH. i have example code of that if you need it

[Astro]

I'd be interested in that. Something I wanted to look into anyway.

Best regards,
Astro.

[Astro]

Dude - that is weird.

XP errors with "Integer divide by zero", whilst Vista does.... precisely nothing about the error and keeps on executing.

Vista Ultimate x64 SP2.

It does load up the CPU though - 50% usage (Core 0 is nearly maxed). Other than this, it appears to run normally.

EDIT: Confirmed the CPU load is due to your app as I forced it to run on Core 1 and it maxed that out instead.

Best regards,
Astro.

[Slugsnack]

I'd be interested in that. Something I wanted to look into anyway.

Best regards,
Astro.

here you go :

Code Select Expand

include \masm32\include\masm32rt.inc

.code
    Start:

xor ebx, ebx

assume fs:nothing
push offset ExceptionHandler
push fs:[0]
mov fs:[0], esp

mov dword ptr ds:[ebx], ebx ; OMG THE WORLD IS GONNA END

pop fs:[0]
add esp, 4

    SafeAddr:

    invoke MessageBox, ebx, chr$("Somehow.. we managed not to crash !"), chr$("Incredibly"), ebx
    invoke ExitProcess, ebx

ExceptionHandler proc pExcept:DWORD, pFrame:DWORD, pContext:DWORD, pDispatch:DWORD

mov eax, pContext
mov ecx, offset SafeAddr
mov [eax].CONTEXT.regEip, ecx
mov eax, ExceptionContinueExecution

ret
ExceptionHandler endp

    end Start

[Ficko]

running windows 7 RTM and the application did crash

XP errors with "Integer divide by zero", whilst Vista does.... precisely nothing about the error and keeps on executing.
Vista Ultimate x64 SP2.

I do have "Vista Ultimate x64 SP2." as well.
Could this be a 64-bit problem ? :eek

i have example code of that if you need it

Thanks for the code I do use simile code as well.
But even if you set up the final exception handling the handler routine never get executed does'nt matter you call RaiseException or causing an exception by other means.

[Astro]

That's great! Thanks!

Best regards,
Astro.

[Astro]

I do have "Vista Ultimate x64 SP2." as well.
Could this be a 64-bit problem ? Eek

Hmm - reading around, there was a problem in GDI+ that could cause a DoS against explorer.exe (and could be used for code execution) which was invoked by raising an integer divide by zero exception through a bad icon. Bad AVI files could cause similar results, too, dragging down explorer.exe with the error.

I'm wondering if MS disabled this error to fix their problem?????? The fix was included in "a" service pack for Vista, but it is unclear if this is SP1 or SP2.

I've got an SP1 disk unfortunately, so no way to test this on a Vista gold install.

Best regards,
Astro.

[Ficko]

MS disabled this error to fix their problem

Is not only div by zero that behaves strange in fact all exceptions but only if generated in a message loop.

[Astro]

MS disabled this error to fix their problem

Is not only div by zero that behaves strange in fact all exceptions but only if generated in a message loop.

Maybe it is to help prevent applications from locking up, so the user can quit them more easily? I've noticed under Vista that apps that did stop responding continued to allow the close button to be pressed.

Best regards,
Astro.

[Slugsnack]

tested on server 2008 SP2 and it crashes correctly there too. i'm afraid i don't have vista installed though so can't help you further than this : [

[evlncrn8]

bear in mind for vista and later you need to have your seh handler 'registered' using the /SAFESEH compiler setting, and marking the seh code as safe...
the old fs:[0] trick, while it seems to work may not under a lot of circumstances.. if you need to do it at runtime i think you also need to use encodepointer
api..

[Ficko]

bear in mind for vista and later you need to have your seh handler 'registered' using the /SAFESEH compiler setting, and marking the seh code as safe...
the old fs:[0] trick, while it seems to work may not under a lot of circumstances.. if you need to do it at runtime i think you also need to use encodepointer
api..

Thanks this are good points but still not explains the phenomenon above.

An exception can happen in any portion of the code even in message loop - intented or not -
I personaly prefer that the system let me know what happening or just-in-time debbuger takes over instead of let the program go into a half hibernated state. :naughty:

[Astro]

bear in mind for vista and later you need to have your seh handler 'registered' using the /SAFESEH compiler setting, and marking the seh code as safe...
the old fs:[0] trick, while it seems to work may not under a lot of circumstances.. if you need to do it at runtime i think you also need to use encodepointer
api..

Thanks this are good points but still not explains the phenomenon above.

An exception can happen in any portion of the code even in message loop - intented or not -
I personaly prefer that the system let me know what happening or just-in-time debbuger takes over instead of let the program go into a half hibernated state. :naughty:

I still think MS, for one reason or another, are simply supressing the exception.  :eek

Right this minute I know too little to write something but I shall be interested to know if it is possible to provoke any kind of exception handling, or indeed, handle the exception *at all* using custom handlers or whatever.

But even if you set up the final exception handling the handler routine never get executed does'nt matter you call RaiseException or causing an exception by other means.

EDIT: Ooops - I think that is what you meant here.

Best regards,
Astro.