BSOD while running Orbiter....Memory Dump included

[n122vu]

While running the Atlantis Launch tutorial, I got a BSOD just as Atlantis approached the ISS.  


Microsoft (R) Windows Debugger  Version 6.6.0007.5
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\WINDOWS\MEMORY.DMP]
Kernel Summary Dump File: Only kernel address space is available

Symbol search path is:
C:\WINDOWS\Symbols;symsrv*symsrv.dll*C:\Windows\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 2) UP Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp2_gdr.050301-1519
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055a420
Debug session time: Wed Dec 20 19:51:53.718 2006 (GMT-6)
System Uptime: 0 days 22:51:15.363
Loading Kernel Symbols
.............................................................................................................................
Loading User Symbols
PEB is paged out (Peb.Ldr = 7ffdb00c).  Type ".hh dbgerr001" for details
Loading unloaded module list
............................
ERROR: FindPlugIns 8007007b
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 8E, {c0000005, bf81278b, edd597cc, 0}

Probably caused by : win32k.sys ( win32k!GreExtTextOutWLocked+fcf )

Followup: MachineOwner
---------

kd> !analyze -v
ERROR: FindPlugIns 8007007b
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)
This is a very common bugcheck.  Usually the exception address pinpoints
the driver/function that caused the problem.  Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003.  This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG.  This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG.  This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: bf81278b, The address that the exception occurred at
Arg3: edd597cc, Trap Frame
Arg4: 00000000

Debugging Details:
------------------


EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The
memory could not be "%s".

FAULTING_IP:
win32k!GreExtTextOutWLocked+fcf
bf81278b 83634400        and     dword ptr [ebx+44h],0

TRAP_FRAME:  edd597cc -- (.trap ffffffffedd597cc)
ErrCode = 00000002
eax=00040043 ebx=00000000 ecx=edd59ab0 edx=bfa49e68 esi=edd59d38 edi=00000d0d
eip=bf81278b esp=edd59840 ebp=edd59a98 iopl=0         nv up ei pl nz na po nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010202
win32k!GreExtTextOutWLocked+0xfcf:
bf81278b 83634400        and     dword ptr [ebx+44h],0 ds:0023:00000044=????????
Resetting default scope

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0x8E

PROCESS_NAME:  orbiter.exe

LAST_CONTROL_TRANSFER:  from 8051d6a7 to 8053331e

STACK_TEXT:  
edd59394 8051d6a7 0000008e c0000005 bf81278b nt!KeBugCheckEx+0x1b
edd5975c 804df235 edd59778 00000000 edd597cc nt!KiDispatchException+0x3b1
edd597c4 804df1e6 edd59a98 bf81278b badb0d00 nt!CommonDispatchException+0x4d
edd597cc bf81278b badb0d00 bfa49e68 00000000 nt!KiExceptionExit+0x18a
edd59a98 bf813c74 edd59d38 e3a0a4dc e3a0a538 win32k!GreExtTextOutWLocked+0xfcf
edd59c00 bf80dee2 edd59d38 7ffdf2b0 0000006c win32k!GreBatchTextOut+0x344
edd59d54 804de7be 00000092 00a9f56c 00a9fad0 win32k!NtGdiFlushUserBatch+0x11b
edd59ddc 804fa4da f75a7b85 8639c6c0 00000000 nt!KiFastCallEntry+0xca
edd59de0 f75a7b84 8639c6c0 00000000 0000027f nt!KiThreadStartup+0x16
edd59de4 8639c6c0 00000000 0000027f 00000000 NDIS!___PchSym_+0xc
WARNING: Frame IP not in any known module. Following frames may be wrong.
edd59de8 00000000 0000027f 00000000 00000000 0x8639c6c0


STACK_COMMAND:  kb

FOLLOWUP_IP:
win32k!GreExtTextOutWLocked+fcf
bf81278b 83634400        and     dword ptr [ebx+44h],0

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  win32k!GreExtTextOutWLocked+fcf

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: win32k

IMAGE_NAME:  win32k.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  43446a58

FAILURE_BUCKET_ID:  0x8E_win32k!GreExtTextOutWLocked+fcf

BUCKET_ID:  0x8E_win32k!GreExtTextOutWLocked+fcf

Followup: MachineOwner
---------

kd> lmvm win32k
start    end        module name
bf800000 bf9c1180   win32k     (pdb symbols)          
C:\Windows\symbols\win32k.pdb\D8788E4736B34ED5B8516DBB9D45E9942\win32k.pdb
    Loaded symbol image file: win32k.sys
    Image path: \SystemRoot\System32\win32k.sys
    Image name: win32k.sys
    Timestamp:        Wed Oct 05 19:05:44 2005 (43446A58 )
    CheckSum:         001CB2E4
    ImageSize:        001C1180
    Translations:     0000.04b0 0000.04e0 0409.04b0 0409.04e0


********************This is the end of my memory dump***************
System specs are as follows:
1.6 Ghz P4, 400Mhz FSB
1.0 GB RAM
20GB Hard Drive (Windows)
80GB Seagate Barracuda Hard Drive (Files, etc)
256MB Sapphire Radeon 9250 Video Card

It looks like a driver fault of some sort, but I'm not sure which.  Could be the vid card.  Can anyone assist with this?

Thanks,

Victor Uniform

[Doug Beachy]

It is most likely your video driver corrupting kernel memory.  Although the crash occurred in win32k.sys and not your
actual video driver, it is not uncommon for a kernel process to be the "victim" of a bug in a different kernel process
since all kernel drivers run at ring 0; i.e. in the same memory space and privilege level.  It also could be a bad RAM
DIMM or other hardware problem.

This is definitely not an Orbiter bug because it is impossible for a normal Windows process to cause a kernel dump on
a properly running system -- normal processes run at ring 3, and cannot corrupt kernel memory.  The only time I have
seen kernel dumps was when I had a driver or hardware problem.  I have also seen overheated video cards cause
kernel dumps as well.

Were you running full-screen or in a window when the crash occurred?   Has it ever happened before?  Are you
running the latest Radeon video driver?

[n122vu]

Doug,

Thanks for confirming my suspicions.  I was also betting either video or RAM.  

Running full screen, 800x600, 16bpp.  I am running the latest (available) driver for my card.  ATI dumped support for
the 9250 card about six months ago, so I'm stuck with an equally old driver.  

This did occur once before, but I did not have debugging set up to trap the kernel error, thus I lost the memory
dump.  Last time was about a week and a half ago.  During that session, I was running at 1024x768, 16bpp.  I have
been reluctant to run Orbiter since the first BSOD, and this is only about the 4th time I've launched since.  

I'm hoping I can come up with a solution that will not involve upgrading my hardware, since I'll have a new little
Orbinaut arriving at the base in July.  But if my current hardware fails me, I might be grounded for a while.  Any
help/ideas/advice would be greatly appreciated.

Thanks,

n122vu

[n122vu]

Something else I just observed.  I unzipped the base Orbiter package into a separate folder.  I didn't install Orbiter
Sound, as I wanted to get a 'control' test.  I pulled up task manager and left the performance tab up while running
Orbiter in a 640x480 window.  The Orbiter launcher had little or no impact, but the sim itself was a different story.  
The moment I launched a sim, processor usage pegged out to 100% and remained there until I closed the simulation
session.

This surprised me, as I had theorized that possibly the high-resolution textures were putting a strain on my system.  
Apparently this was not the case, since it happened with the base installation package.  My conclusion is that the
over-working of the processor is causing excessive heat and strain on both the processor and the video card.  

If anyone has any thoughts on this, I'd be happy to hear them.  

Thanks,
n122vu



Post Edited ( 12-22-06 02:40 )

[Doug Beachy]

Note that it is normal for Orbiter to run the CPU at 100% utilization; this simply means that Orbiter is running
continuously in its main loop and rendering as many frames per second as possible.  This is also true of virtually all
games and simulations.

It is of course quite possible that heat is the problem, either for the CPU or (more likely) the video card.  Running high-
res textures does cause higher temps on the video card, since video card heat is directly proportional to the work the
card is doing in Orbiter's main loop.  

I have seen overtemps cause kernel crashes; however, based on past experience it is more likely a bug in the video
driver that is corrupting kernel memory.  Unfortunately since it appears that your video card and driver are now
unsupported, the only way to test that is to swap out the video card for a newer (supported) one.

[n122vu]

Doug - thanks for the info on both the CPU utilization and the tips on heat.  It makes sense, and with the
line "DEFAULT_BUCKET_ID: DRIVER FAULT" seen in the kernel dump, I tend to agree with your diagnosis that the
video driver is the most likely cause.  

A new development - 2 days later I began to get memory-related error messages.  I have since moved back to my
previous PC, which has a bit faster processor but less memory (and also a MUCH LARGER CPU FAN, and a case fan
which actually channels air/heat away from the CPU).  Another bit of good news is that I went to ATI's website after
the move and discovered that since AMD has acquired ATI, they have again picked up support for my video card,
which I did move into my current PC.  Hopefully I will not see more of the same issues with this configuration.  So far,
so good.  The only problems I've seen are those that I mention over in the DGIV Beta thread.  

Thanks again for the advice and info.

Regards,

n122vu