Faulting application name: dreamdaemon.exe, version: 5.0.510.1341, time stamp: 0x57291d76
Faulting module name: byondcore.dll, version: 5.0.510.1341, time stamp: 0x57291c69
Exception code: 0xc00000fd
Fault offset: 0x000c6756
Faulting process id: 0x1504
Faulting application start time: 0x01d1ab2ab92cd15d
Faulting application path: C:\Program Files (x86)\BYOND\bin\dreamdaemon.exe
Faulting module path: C:\Program Files (x86)\BYOND\bin\byondcore.dll
Report Id: 611cf968-1786-11e6-80ba-0cc47ab3459f
Faulting package full name:
Faulting package-relative application ID:
ID:2082681
May 11 2016, 12:54 pm
|
|||||||||||||
| |||||||||||||
Dunno if you can glean anything from the event log
|
Of course the most likely outcome of a stack trace will be to say that it's calling DoProc() repeatedly, so I don't know if that will help all that much, since it won't say which proc is doing all that recursion.
|
Unsure if this is related but apparently changing an atom's icon from a DMI to a gif at runtime is causing crashes.
|
In response to Pomf123
|
|
Pomf123 wrote:
Unsure if this is related but apparently changing an atom's icon from a DMI to a gif at runtime is causing crashes. There's a .gif fix already in the can, which I think is the same issue you're talking about. I think that's not related at all to this stack overflow, though. |
(11b8.d04): Access violation - code c0000005 (!!! second chance !!!) this helpful? |
Nope, crash info from widthInTiles() isn't helpful without a stack trace. The only way for that routine to crash is when the icon pointer is invalid.
|
STACK_TEXT: |
I think to make any headway on this I'd need a full stack trace, like from WinDbg. The Linux build would have told you the last few procs called which are probably a vital clue, although the Windows build doesn't have a way to get you that info.