i just made this prog but when i run it gives me a blue screen saying that a fatal exception has been caused at 017F:BFF9DFF .Then when i press enter it gives a white box saying that an invalid page fault has been caused at 0001:000049bb in kernel386.exe. Ollydbg tells me that the prob is a stack overflow. Its an MDI richedit prog. The prob occurs after the richedit dll is loaded but before the window shows. Also the system has to be restarted after the crash. How do i go abt debugging the prob. Should i use sice? If so how? This message was edited by MovingFulcrum, on 6/3/2001 1:01:00 PM
I had a similar problem once. It was due to one of my procedure not preversing the esi register. The procedure was called in response to a WM_CHAR message. After calling the procedure, all applications crashed one after the other. It will help if you could post the code of your program.
The source is too long to be posted here. But if u email me u can get it. Its arnd 250 lines and 9KB.
Ok i have got to know what the problem is but it is exrtrmely weird. The program gives a stack overflow when it executes WinMain!!!!!!!!!!!!! i got to know this throught ollydbg. Can any1help. Here is my initialization code - INVOKE GetCommandLine mov CommandLine, eax call InitCommonControls invoke LoadLibrary, addr RichEditDLL mov hRichEdit,eax invoke GetModuleHandle, NULL mov hInstance,eax INVOKE WinMain, hInstance, NULL, CommandLine, SW_SHOWDEFAULT invoke ExitProcess ,eax After the last push to hInstance after executing the call to winmain the prog crashes with a stack overflow! How is this possble? Can any1 help???????
Its entirely possible, since WINMAIN is where you're unique behavior of your program will reside.. (or stem from anyways). So basically your have traced out the fact that YOUR coding has caused a stack overflow error.. (crashes when WINMAIN is actually exccuted, after the last push to the stack). I would look for a routine that has a PUSH (or a POP) in a loop by itself. Such that as it loops it PUSH another DWORD etc. etc. with out poping and causing the stack to overflow. Another trick i use in these cases is placing
Comment out or replace with the above jump sequence all your 'behavior' code (that which lies within your if/elseif/endif stuctures (except the WM_CLOSE / WM_DESTROY conditions obviousely :) ). Once you have forced your program to become a NULL application with no behaviors, sequencially step in and allow more behaviors to perform untill you get your crash again.. then you will know exactly what 'fragment' of code made the crash this complie, vs. the previous compile. (I personally use the jmp @F because i can CUT & PASTE it easier than removing comments. If you dont want to post the source here, put it up on a cheap web-page to D/l and look at.. (Im kinda fussy with E-mail, i never check it cause it get tooooo much life insurance/porn adds.) NaN
.if (...) ; JUMP OVER EVERTHING ELSE jmp @F .... your code fragment for this case .... @@: .endif
As well, after re-reading your 'symptoms' I have a strong feeling your poping more than your pushing (overall, loops or not), such that when WINMAIN is exited, it wants to pop the parameters passed to WINMAIN (cleanup after the function call) but can't because the stack pointer is already at, or closer to 0 than the number of parameters passed in the first place (this would be a critical problem as your describing). NaN This message was edited by NaN, on 6/3/2001 11:19:19 PM
Ok i got the answer to my problem. But pls pls dont kill me when u tell you. Thankx to Nan actually i dont think i would have been able to solve such a silly bug or rather typo wihtout ur help. Actually i typed out CreateWindowEx 2 times. No wonder! :-)
since Windows is a stable operating system, it reacts to a simple programming error with a complete crash :D If anybody like to, try a nice effect I found under Win95 - a div 0 exception during a timeSetEvent Proc - this leads to an immediate turn off the computer!
That's a cool feature Beaster - M$ just forgot to add the documentation for that to the SDK. :)
If MS had to look after stack crashes, they could not afford to give us talking paperclips.