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:
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
Quote xor eax, eax
div al
You are attempting to divide by zero...
Quoteso 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.
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
I'd be interested in that. Something I wanted to look into anyway.
Best regards,
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.
Quote from: Astro on August 11, 2009, 06:30:34 PM
I'd be interested in that. Something I wanted to look into anyway.
Best regards,
Astro.
here you go :
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
Quote
running windows 7 RTM and the application did crash
Quote
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
Quote
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.
That's great! Thanks!
Best regards,
Astro.
QuoteI 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.
Quote
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.
Quote from: Ficko on August 11, 2009, 07:39:49 PM
Quote
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.
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 : [
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..
Quote from: evlncrn8 on August 13, 2009, 06:37:40 AM
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:
Quote from: Ficko on August 13, 2009, 08:13:40 AM
Quote from: evlncrn8 on August 13, 2009, 06:37:40 AM
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.
QuoteBut 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.
Interesting...
We might be getting somewhere with this (but not entirely...).
http://www.eggheadcafe.com/conversation.aspx?messageid=29220332&threadid=29220332
:eek
Nice... so they remove the app from the screen ad suppress all error messages (except when debugging, apparently). How does Vista know the difference between "normal" and "debugged"?
Best regards,
Astro.
IsDebuggerPresent could be used or read it straight from PEB (BeingDebugged) or CheckRemoteDebuggerPresent, there's quite a few ways of checking if your app is being debugged
That's crass I didn't know about this "Ghosting" shit. :eek
Nevertheless there must be some more to it because this "ghosting" was apparently introduced by XP already but XP responding well to exceptions in message loop and
I tryed out "DisableProcessWindowsGhosting" nothing really changed. :'(
Quote from: Ficko on August 15, 2009, 03:55:35 PM
That's crass I didn't know about this "Ghosting" shit. :eek
Nevertheless there must be some more to it because this "ghosting" was apparently introduced by XP already but XP responding well to exceptions in message loop and
I tryed out "DisableProcessWindowsGhosting" nothing really changed. :'(
...so either the article is wrong, the MS articles are wrong, or Windows is buggy to hell. :eek
I didn't know XP had ghosted windows.
http://msdn.microsoft.com/en-us/library/ms648415(VS.85).aspx
Best regards,
Astro.