Fault bucket , type 0
Event Name: BEX
Response: Not available
Cab Id: 0
Problem signature:
P1: dreamdaemon.exe
P2: 5.0.509.1300
P3: 55fc477c
P4: byondcore.dll
P5: 5.0.509.1300
P6: 55fc4676
P7: 0024ecd2
P8: c0000409
P9: 00000002
P10:
ID:1938297
Sep 19 2015, 11:27 am
|
|||||||||||||
| |||||||||||||
In response to Lummox JR
|
|
Lummox JR wrote:
Please include the full build in the report. I know there's only one right now, but it's important for keeping track. Was runtime and was set via a verb, it had worked fine on several different changes then just up and crashed when setting it back to normal [1, 0, 0, 0, |
In response to Pomf123
|
|
/client/verb/changeclientcolor() |
Hmm. Can you get better info from your event viewer than that? The list of parameters to the problem signature is useless, because apparently Microsoft has been playing around with that for some time and the subject is more or less Google-proof. I need to know the offset within byondcore.dll where the fault happened, and I think I can use that to diagnose the crash.
|
This is the only other entry i have regarding that crash,
Faulting application name: dreamdaemon.exe, version: 5.0.509.1300, time stamp: 0x55fc477c |
Hrm, rats. The crash offset isn't giving me enough to go on after all. If I could see further back in the stack it might help.
|
As I was unable to reproduce this, but I did find other issues, I recommend retesting in 509.1301. Chances are very good that the issue was solved as part of the other fixes.
If it crashes again, it'd be best if you can get more of a stack trace so I can see not only where it crashed but what the callers were. (Running a debugger can get that info, at least in terms of the offsets in byondcore.dll which should be all I need.) |
I'll also need to see where you set the client color, whether it was at runtime or compile-time. There's already a report for issues with this at compile-time, but if there's a runtime issue I want to see how that's triggered.