Also ich hab seit ca 1 woche ein großes Problem mit GTA 4.
UNd zwar ist es so dass ca nach 10-15 ein Bluescreen kommt mit anschließendem Neustart. Leider ist der Bluescreen so kurz, dass ich nicht lesen kann was da steht. Nicht dass ich was damit anfangen könnte aber ihr vielleicht:D:D
Manchmal kommt auch kein bluescreen sondern so komische Grafikbugs also so schlieren oder Linien. Vom eigentlichen Bildschirm sieht man nichts mehr. Allerdings läuft der Sound weiter. Aber ich komme auch nicht in den Taskmanager.
Ich habe auch schon Gegoogled und auch was gefunden.
RAM war das hauptthema.
Mein RAM scheint aber ok zu sein.
Hab schon MemTest ca. 7 stunden laufen lassen
MemTest86+ auch schon
EVEREST Ultimate Edition Stresstest und ein
BurnInTest. Nirgens kamen Fehler.
auch einemöglichkeit war die Temperatur.
Also hab ich mit EVERESt die Temeratur nach ca 5 min ausgelesen.
Die war aber vollkommen unproblematisch. Also so bei um und bei 60°.
So langsam bin ich mit meinem Latein am ende und hab kein Plan was ich noch machen soll.
Vor allem hatt es ja seit das spiel raus ist und ich es gekauft habe wunderbarohne fehler funktioniert.
Wie gesagt erst seit ca 1 woche.
Ach ja hier mein betriebssystem.
WinXP SP3
gForce 8800GTS @ 640mb
Abit IP-95
2 GB RAM
Treiber sind alle Aktuell und auch Net.Framework usw. ist alles auf dem neusten stand.
Tya und was soll ich jetzt machen???:(:(
Wäre sehr froh über lösungsvorschläge. (aber ernst gemeinte nicht so was wie spiel zurückgeben oder pc neu kaufen.)
//edit
habs grad naochmal gemacht. diesmal kam ich gar nicht mehr in spiel. kam nur noch bis zum ladebildschirm und dann so n grafikfehler. aber diesmal kommte ich noch in Taskmanager. Als ich dann GTA über Taskmanager beendet hatte kam Son PIEP und dann war der PC eingefrohren. Half nur noch die Reset Taste.:(:(:(
Hab nochmal die Minidump Datei vom gestrigen Bluescreen mit dem WinDbg ausgelesen.
Kann damit allerdings nichts anfangen.Ihr vielleicht?
Microsoft (R) Windows Debugger Version 6.10.0003.233 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\WINDOWS\Minidump\Mini042009-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: *** Invalid ***
************************************************** **************************
* Symbol loading may be unreliable without a symbol search path. *
* Use .symfix to have the debugger choose a symbol path. *
* After setting your symbol path, use .reload to refresh symbol locations. *
************************************************** **************************
Executable search path is:
************************************************** *******************
* Symbols can not be loaded because symbol path is not initialized. *
* *
* The Symbol Path can be set by: *
* using the _NT_SYMBOL_PATH environment variable. *
* using the -y <symbol_path> argument when starting the debugger. *
* using .sympath and .sympath+ *
************************************************** *******************
Unable to load image ntoskrnl.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
*** ERROR: Module load completed but symbols could not be loaded for ntoskrnl.exe
Windows XP Kernel Version 2600 (Service Pack 3) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Machine Name:
Kernel base = 0x804d7000 PsLoadedModuleList = 0x805634c0
Debug session time: Mon Apr 20 11:29:22.781 2009 (GMT+2)
System Uptime: 0 days 0:18:49.521
************************************************** *******************
* Symbols can not be loaded because symbol path is not initialized. *
* *
* The Symbol Path can be set by: *
* using the _NT_SYMBOL_PATH environment variable. *
* using the -y <symbol_path> argument when starting the debugger. *
* using .sympath and .sympath+ *
************************************************** *******************
Unable to load image ntoskrnl.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
*** ERROR: Module load completed but symbols could not be loaded for ntoskrnl.exe
Loading Kernel Symbols
.................................................. .............
.................................................. ..........
Loading User Symbols
Mini Kernel Dump does not contain unloaded driver list
Unable to load image nv4_disp.dll, Win32 error 0n2
*** WARNING: Unable to verify timestamp for nv4_disp.dll
*** ERROR: Module load completed but symbols could not be loaded for nv4_disp.dll
************************************************** *****************************
* *
* Bugcheck Analysis *
* *
************************************************** *****************************
Use !analyze -v to get detailed debugging information.
BugCheck EA, {88a080c0, 897a7120, 89a28008, 1}
*** WARNING: Unable to verify timestamp for mssmbios.sys
*** ERROR: Module load completed but symbols could not be loaded for mssmbios.sys
***** Kernel symbols are WRONG. Please fix symbols to do analysis.
************************************************** *******************
* Symbols can not be loaded because symbol path is not initialized. *
* *
* The Symbol Path can be set by: *
* using the _NT_SYMBOL_PATH environment variable. *
* using the -y <symbol_path> argument when starting the debugger. *
* using .sympath and .sympath+ *
************************************************** *******************
************************************************** ***********************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
************************************************** ***********************
************************************************** ***********************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
************************************************** ***********************
************************************************** *******************
* Symbols can not be loaded because symbol path is not initialized. *
* *
* The Symbol Path can be set by: *
* using the _NT_SYMBOL_PATH environment variable. *
* using the -y <symbol_path> argument when starting the debugger. *
* using .sympath and .sympath+ *
************************************************** *******************
************************************************** *******************
* Symbols can not be loaded because symbol path is not initialized. *
* *
* The Symbol Path can be set by: *
* using the _NT_SYMBOL_PATH environment variable. *
* using the -y <symbol_path> argument when starting the debugger. *
* using .sympath and .sympath+ *
************************************************** *******************
Probably caused by : nv4_disp.dll ( nv4_disp+ee717 )
THREAD_STUCK_IN_DEVICE_DRIVER (ea)
The device driver is spinning in an infinite loop, most likely waiting for
hardware to become idle. This usually indicates problem with the hardware
itself or with the device driver programming the hardware incorrectly.
If the kernel debugger is connected and running when watchdog detects a
timeout condition then DbgBreakPoint() will be called instead of KeBugCheckEx()
and detailed message including bugcheck arguments will be printed to the
debugger. This way we can identify an offending thread, set breakpoints in it,
and hit go to return to the spinning code to debug it further. Because
KeBugCheckEx() is not called the .bugcheck directive will not return bugcheck
information in this case. The arguments are already printed out to the kernel
debugger. You can also retrieve them from a global variable via
"dd watchdog!g_WdBugCheckData l5" (use dq on NT64).
On MP machines (OS builds <= 3790) it is possible to hit a timeout when the spinning thread is
interrupted by hardware interrupt and ISR or DPC routine is running at the time
of the bugcheck (this is because the timeout's work item can be delivered and
handled on the second CPU and the same time). If this is the case you will have
to look deeper at the offending thread's stack (e.g. using dds) to determine
spinning code which caused the timeout to occur.
Arguments:
Arg1: 88a080c0, Pointer to a stuck thread object. Do .thread then kb on it to find
the hung location.
Arg2: 897a7120, Pointer to a DEFERRED_WATCHDOG object.
Arg3: 89a28008, Pointer to offending driver name.
Arg4: 00000001, Number of times this error occurred. If a debugger is attached,
this error is not always fatal -- see DES*****ION below. On the
blue screen, this will always equal 1.
Debugging Details:
------------------
***** Kernel symbols are WRONG. Please fix symbols to do analysis.
************************************************** *******************
* Symbols can not be loaded because symbol path is not initialized. *
* *
* The Symbol Path can be set by: *
* using the _NT_SYMBOL_PATH environment variable. *
* using the -y <symbol_path> argument when starting the debugger. *
* using .sympath and .sympath+ *
************************************************** *******************
************************************************** ***********************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
************************************************** ***********************
************************************************** ***********************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
************************************************** ***********************
************************************************** *******************
* Symbols can not be loaded because symbol path is not initialized. *
* *
* The Symbol Path can be set by: *
* using the _NT_SYMBOL_PATH environment variable. *
* using the -y <symbol_path> argument when starting the debugger. *
* using .sympath and .sympath+ *
************************************************** *******************
************************************************** *******************
* Symbols can not be loaded because symbol path is not initialized. *
* *
* The Symbol Path can be set by: *
* using the _NT_SYMBOL_PATH environment variable. *
* using the -y <symbol_path> argument when starting the debugger. *
* using .sympath and .sympath+ *
************************************************** *******************
FOLLOWUP_IP:
nv4_disp+ee717
bf100717 7506 jne nv4_disp+0xee71f (bf10071f)
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: nv4_disp+ee717
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nv4_disp
IMAGE_NAME: nv4_disp.dll
BUCKET_ID: WRONG_SYMBOLS
Followup: MachineOwner
---------
so noch mal gemacht und wieder ohen bluescreen aber mit taskmanager und ohne dass sich der pc aufhängt. Die letzten male kamm es immer beim laden. und so sieht das dann aus.
