ID:1918830
 
BYOND Version:508
Operating System:windows server 2012
Web Browser:Firefox 41.0
Applies to:Dream Daemon
Status: Open

Issue hasn't been assigned a status value.
Faulting application name: dreamdaemon.exe, version: 5.0.508.1295, time stamp: 0x55cb791c
Faulting module name: MSVCR120.dll, version: 12.0.21005.1, time stamp: 0x524f7ce6
Exception code: 0xc0000005
Fault offset: 0x0000f608
Faulting process id: 0x1d54
Faulting application start time: 0x01d0d85d3ac5cc39
Faulting application path: C:\Program Files (x86)\BYOND\bin\dreamdaemon.exe
Faulting module path: C:\Program Files (x86)\BYOND\bin\MSVCR120.dll
Report Id: c99a8d70-4451-11e5-93fc-001e8cf19ccb
Faulting package full name:
Faulting package-relative application ID:
Faulting application name: dreamdaemon.exe, version: 5.0.508.1295, time stamp: 0x55cb791c
Faulting module name: byondcore.dll, version: 5.0.508.1295, time stamp: 0x55cb7814
Exception code: 0xc0000005
Fault offset: 0x000b5d56
Faulting process id: 0x11a4
Faulting application start time: 0x01d0d6f5da608c92
Faulting application path: C:\Program Files (x86)\BYOND\bin\dreamdaemon.exe
Faulting module path: C:\Program Files (x86)\BYOND\bin\byondcore.dll
Report Id: 9048c1db-6ee1-4b16-b1c0-53b1ca73e916
Faulting package full name:
Faulting package-relative application ID:
happened on my local, windows 10 x64 pro
The first of those crashes is impossible to trace because it's not in our code directly. The second does appear to be in our code; so far I'm not entirely sure where it's at so I'll try to narrow that down.
alright, thanks.
are there any tools incoming for feedback on crashes?
In response to Aranclanos
I don't know what you mean. The info I can get out of a crash is limited by what the end user has available. On Linux, crashes at least have a stack unwind (usually) which often helps, but in Windows the info is more limited. Although I've often thought SS13 Windows hosts would benefit from installing a debugger so they can at least pull that stack unwind information.
In response to Lummox JR
Lummox JR wrote:
I don't know what you mean. The info I can get out of a crash is limited by what the end user has available. On Linux, crashes at least have a stack unwind (usually) which often helps, but in Windows the info is more limited. Although I've often thought SS13 Windows hosts would benefit from installing a debugger so they can at least pull that stack unwind information.

I tried that and all i get is a ginormo crash dump
A debugger like the one built into VS2013 (or even much older versions of Visual Studio) should be capable of breaking into the crashed process and showing you the call stack. IMO, Windows' own debugger is not the ideal tool for this, because their dump files are darn near useless for serious debugging.
can we expect anything like that built-in byond in a next update?
In response to Aranclanos
Aranclanos wrote:
can we expect anything like that built-in byond in a next update?

A debugger is a sophisticated third-party tool.
we still don't have anything
In response to Aranclanos
What I mean is, anyone can install a debugger if they wish. It can provide info about the call stack and other useful info that vanilla Windows won't. But it would be impossible to provide anything like that built in, because that's like asking if the program suite can include a full-featured video player and tax prep software.

Now if you mean whether it'd be possible to include a VM debugger in BYOND to detect logic errors in .dmb files, that's a completely different subject. (Short answer: Probably not, but I wouldn't close the door on it entirely.) Debugging bytecode is a matter of adding various hooks; debugging binary machine code needs a specific tool.
In response to Lummox JR
Lummox JR wrote:
What I mean is, anyone can install a debugger if they wish. It can provide info about the call stack and other useful info that vanilla Windows won't. But it would be impossible to provide anything like that built in, because that's like asking if the program suite can include a full-featured video player and tax prep software.

Now if you mean whether it'd be possible to include a VM debugger in BYOND to detect logic errors in .dmb files, that's a completely different subject. (Short answer: Probably not, but I wouldn't close the door on it entirely.) Debugging bytecode is a matter of adding various hooks; debugging binary machine code needs a specific tool.
have you got a suggestion for a debugger on windows that you know can expose the stack rewind?
As I mentioned the VS 2013 debugger ought to be capable of this--though I haven't got it working with regular programs that weren't run in it in the first place yet, so I don't know what's needed to set that up.

I haven't researched debuggers very well myself, because I simply use the one I already have. This will probably require a little Google legwork.
must have missed that, thanks
well debugdiag doesn't work, just gives an internal stack unwind rather than the 'useful' info linux gives. http://ss13.pomf.se/uploads/2015-08-22_14-25-22.txt
That might be useful if you can get it to spit out the actual full offset in the .dll rather than trying to put it in terms of a function name.