Hola, I'm kinda wonderding what's happening to my beloved program during execution sometimes... I "know" where the error "might" reside inside my code... but when I check the flow with the debugger everything works well, if I just let it run as it's supposed to be it shows me a MessageBox saying something like "This applications has been closed due to an invalid process" with nice Close, Debug & Details.. buttons. Debug button doesn't work.. The details tells me that it happened due to an invalid thing inside kernel... OK! I know that my not Kernel.dll is not the malefactor. I'd just love to know why it makes fun of me running alright when I'm chasing it with my debugger and why it crashes if I leave it running. Anyone knows where I should start searching the bug?
I found the gangster... it's GlobalLock which returns with eax==NULL...
Nope... I'm still clueless > :(
You must break your programs execution into smaller pieces to find the error. Put message boxes all over the place to see how far your program gets before the error. Use the divide and conquer aproach:
You might not find out why exactly, but this methode will certainly tell you where. Your program would have to be monsterous in size for this not to narrow down to a fairly small section of code quickly. bitRAKE This message was edited by bitRAKE, on 3/27/2001 3:21:45 PM
A. Put a message box in the 'center' of the execution path B. Run the program C. Didn't see the message box: 1. Execution path = Execution path start to message box 2. Goto A D. You saw the message box: 1. Execution path = Message box to end of execution path 2. Goto B
Here's my favorite trick. First, I don't use message boxes, I use a console window ALONG with whatever windows the program makes (umm, if your program IS a console app already, you have to do this with a debug file). That means I don't have to dismiss boxex every time the message loop pumps. And no BEEPING BEEPING BEEPING STOP THE BEEPING. So, inside each procedure I place a mesasage to print the proc name, and just before it ret's, I place a proc name DONE message. So, run the program. If it GPF's, check the dialog. You'll see exactly WHICH proc is crashing. It's the last one, and it doesn't say DONE. Step next, add LOTS more messages in this routine. Like "A", "B" (numbers are faster to type) and recompile. This way, if you need you can tie it down to the individual line that's faulting. I've got some macros I keep inside my \include\ directory just for this. They dump to either message boxes, console windows, or files. They also print numbers and strings too. You can grab em off my site if you want. ------------------------ "Marge, when I join an underground cult I expect a little support from my family."
JimmyClif It happen to me before.
OK! I know that my not Kernel.dll is not the malefactor.As well it could be if you supply it with wrong info. For example say - you have a buffer and you overwrite it into a handle and then call kernel api. There is nothing to check wrong address and bingo kernel crash. This is only suggestion as I don't know your code. forge
Hello and thakns for the tips, I'm not back home right now but I try to post the two lines which make my program crash as detailled as possible: Winsock :) related.. invoke ioctlsocket,sock,FIONREAD,ADDR Sizetoread invoke GlobalAlloc,hWnd, GHND, Sizetoread+10 ok, I guess it looks like this ;) So, normally we would use in GlobalAlloc only Sizetoread, right? But that doesn't work.. It stops crashing when I write Sizetoread+10, and honestly I have no clue what's going on there? I checked out Icz http.asm and he really uses only Sizetoread when invoking GlobalAlloc .. and as my code looks mostly similar to his I dunno what could be wrong with my Sizetoread ? I don't use it anywhere else in my codings.. Hope my questions aren't too confusing. Jimmy
Ernie, this link (http://www.hiroshimator.com/here.is/ComInAsm) is broken... :(
Hi, this is not the correct address. It should be ComInASM. I assume, Ernie left out the http:// See you! Stefan