Page 1 of 1
Crashing to Microsoft's error reporting
Posted: Thu Apr 06, 2006 7:13
by chopkinsca
If Gzdoom crashes and goes to Microsoft's Send/don't send window, is there any infomation about the crash that can be retrieved and is useful?
There is a screen that has information similar to GZDooms crash dump screen, but you can't hightlight it, let alone copy and paste it. Also, checking the crash log in event viewer only shows a small amount of information.
I'm asking because I get these crashs at 'random' in a project I'm working on. They almost always occur on changing levels, but not always. Recently I did something (not sure what) and can produce the crash everytime. But because it uses the windows crash handler, I can't give much if any information asides from the faulting memory address.
Posted: Thu Apr 06, 2006 9:08
by Graf Zahl
Then please post at least that. It could help somewhat.
I think I am going to revert to the old crash handler from ZDoom 2.0.96 and before. The new one is causing nothing but problems. Half of the time it locks up somewhere and I get no information whatsoever.
Posted: Thu Apr 06, 2006 9:35
by chopkinsca
Okay, I have these two. It's all the information I could get. Not sure what the version is that's showing, but I am using 1.0.04, and redownloaded/installed it an hour ago to make sure.
both are eventid 1000
faulting module gzdoom.exe, version 1.0.3.0, fault address 0x00070b48.
faulting module gzdoom.exe, version 1.0.3.0, fault address 0x00070b40
Posted: Thu Apr 06, 2006 10:18
by Graf Zahl
Unfortunately these adresses are outside the main executable and therefore untraceable.
Sorry.
Posted: Thu Apr 06, 2006 10:52
by chopkinsca
Hmm, that kind of sucks. I suppose the information that would be useful is shown when you choose to view information on the crash report, but I see no way to copy the text. No idea if it creates a dump file somewhere, if it's just temp until you send it to MS, or if it is even useful at all.
Does the fact that the addresses are outside of the main executable mean that it's a system problem, or just something you can't tell from such little information?
If it's not system specific, maybe having the .wad file would help if you could produce the crash on your end, but I don't know about giving someone else something I'm working on. Although, if it could help solve a problem, I'd probably do so. I trust you that you wouldn't steal it.

Posted: Thu Apr 06, 2006 12:34
by Graf Zahl
If you can reproduce the crash with a specific WAD it might help if I could take a look. Don'T worry, I don't steal it - and I won't pass it on to others.
Posted: Thu Apr 06, 2006 14:11
by chopkinsca
Hmm, I was making sure I could reproduce it enough to explain how to do it, and came across some strange things. I noticed that it wouldn't happen if I ran the .wad in different ways (from shortcuts, batch files, or double-clicking the file itself). Running it from a batch file would enable it, but running from a shortcut with the exact same run line wouldn't. Also running it from doombuilder's preset command line would trigger it.
I'd send the map, but I'm getting a headache from trying to figure out how to explain how to reproduce it. I can make it crash anytime I want, it's just the settings of how it's run that it depends on and I can't figure out what ones they are.
Edit: ug, now I can't even reproduce the error if I want to. Maybe it's just a mapping error that caused it, or I imported some graphics wrong. I don't even know what I did to stop it from being reproducable. I've been having it crash sporadically on map changes or restarting from death, but this was the first one I could reproduce (until now). Hopefully it's the last I see of it. Sorry about that.
Posted: Thu Apr 06, 2006 14:57
by Graf Zahl
This sounds more like a hardware or OS problem. Mapping errors normally show consistent results.