ID:1784816
 
BYOND Version:507
Operating System:Windows 7 Home Basic
Web Browser:Chrome 40.0.2214.111
Applies to:Dream Seeker
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:
Game crashes religiously with a ntdll.dll error.


Numbered Steps to Reproduce Problem:
Run a game for a few hours in 507.


Expected Results:
To not crash.
Actual Results:
Crashes after 4-8 hrs.(I usually run it while sleeping to test.)

Taken from a forum that describes what I'm experiencing,not the browser doesn't always crash it's usually Dream Seeker:

My money would be on NIS 2010 as the culprit. Any Internet Security app with a 3rd party firewall will interefere with system services in Windows 7 & Vista. Windows Explorer & Internet Explorer (or default browser) most times with ntdll.dll will be involved. It is an APPHANG followed by an APPCRASH after 30000ms. Then possibly a BSOD.

- fading white background
- never-ending spinning blue circle
- "..Not Responding.." top-right of the screen


Does the problem occur:
Every time? Or how often?
Every time.
In other games?
Haven't tested.
In other user accounts?
Haven't tested.
On other computers?
Yes.

When does the problem NOT occur?
To my knowledge it doesn't "not" occur.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)

Workarounds:
None,not sure what's causing it.
If there's any way to get a stack trace it would help. I know post-XP that's way more difficult. I suspect this is likely crashing inside a memory handler and some memory is getting corrupted, so chances are the actual cause isn't where it's crashing anyway.

This report is still incomplete though, as it might only happen in your specific game (indicating a problem with something you're using, though obviously still a bug), and you haven't tested in older versions. I'm moving this to the regular Bug Reports forum as I doubt this is beta-specific.

Another thing I'd like you to try is running the game in Dream Daemon and joining the game with the Join icon, so you're connected over localhost. In that way we could separate out whether it's the server or client that's crashing.
I actually posted about this a few weeks ago before I made the post here, I've went through all the normal stuff-such as updating dlls, drivers and the like. (Still the problem occurs)

I can easily try it with different games as well it will just take a few hours. I'll try to get more information for you.
The main thing is I need some way to narrow this down.

I would also advise, in case it's in play, turning off threading in your daemon.txt settings if it's set there.
I'll do that. Not sure if I ever turned it on but it's worth a look. Downloading windbg now in order to try to get some stack trace info for you. *also I never knew that existed or what a stack trace was until now- I feel like a kid in a candy store who just found a new flavor ^_^ *
Cool. My gut says that if it's crashing in ntdll it's probably heap corruption, but it might point to something of relevance if it can be traced back to an offset in byondcore.dll. Additionally, sometimes I can catch heap corruption if I run a game in the debugger.

Does this issue happen if the game just sits and no one is playing?
In response to Lummox JR
Yes. I've never really played for 4-8 hours straight and I haven't hosted to allow anyone to play thus far (still in development).

I tend to leave it on overnight to see if I get any bugs I need to fix and just for profiling and testing purposes. I can see if I can host maybe and just not login but I'd need to get a vps for that, I'm not able to configure my firewall properly to host at home(atleast the last time I tried)
If it crashes without intervention (and if you've ruled out threads and whatnot) then that might be something I could leave running in a debugger and see what happens.
Any suggestions on how I should best go about using Windbg on a dream seeker file? Just attach?
I tried using open as executable-but the file type wasn't recognized.
I think you'd want to attach to the process after it starts up.


The dump file I was trying to make doesn't seem to have been written.
Can you glean any information from that screen shot of procdump?
I can also check the events .
Nope, nothing there I can really use. This is hanging rather than crashing? That's kind of odd.
I configured procdump to watch for hung windows *non responsive for 5 seconds or more.*

The game window will go white *not crash persay completely* , give the appcrash error, but the dreamseeker window never closes unless I close it manually.
Ok let's try again!
/*
Loading Dump File [C:\Dumps\strangecrash.dmp]
Comment: '
*** procdump -h dreamseeker.exe strangecrash.dmp
*** Hung window detected: 790d70'
User Mini Dump File: Only registers, stack and portions of memory are available


************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred SRV*C:\SymCache*http://msdl.microsoft.com/download/symbols
Symbol search path is: SRV*C:\SymCache*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Version 7601 (Service Pack 1) MP (4 procs) Free x86 compatible
Product: WinNt, suite: SingleUserTS Personal
Machine Name:
Debug session time: Sun Feb 15 06:54:13.000 2015 (UTC - 6:00)
System Uptime: not available
Process Uptime: 0 days 3:54:19.000
................................................................
....
Loading unloaded module list
...
eax=00213038 ebx=00213038 ecx=00370000 edx=00040000 esi=00370000 edi=00040000
eip=7707b32a esp=00213000 ebp=00213000 iopl=0 nv up ei pl nz na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206
ntdll!RtlpFindUCREntry+0x5:
7707b32a 51 push ecx*/


I'm not sure if I did that right, the file size is 4MB. i sort of expected more info to be displayed.
Hrm, yeah, I'd need a stack trace because that's in ntdll.dll still.

If the game is actually hanging though, that's much easier to catch if I can get it in the debugger.
In that case, can't I just send the .dmp file to you and you can properly debug it?
Or is it something I personally need to do?
If it crashes on its own without intervention then it's probably something I could try running long-term on my own if I had the host files.
It would be more helpful in that case if I could do it myself. Apparently I'm doing something wrong to be unable to read the entire .dmp file.
After I have a dump file- could you talk through the steps I need to open and look at the info?
The dump file really isn't that useful to me. Running a game in the debugger is far more useful, because then I can see exactly where it's crashed and what the state of the call stack is.

I've been able to get by sometimes with a simple instruction offset into byondcore.dll, but since your crash is happening in ntdll.dll that won't work. Plus, if this is a heap corruption issue, my debugger is way more apt to catch it in progress instead of after the fact.
Okay. So can you run me through the steps you use when debugging, which program you use (nothing in depth, just a sequence of steps). I'm asking because learning to do so would be helpful to me as well since the profiler doesn't entirely give that type of insight.
Page: 1 2