Oblivion keeps crashing...

[Deadly_Nightshade]

Oblivion keeps randomly freezing on loading screens, and almost always freezes the entire system when exiting...

(I just updated my video card driver, could that have caused this? If so, how do I revert tot he older version?)

[Gfted1]

To roll back:

 

Start

Control Panel

Performance and Maintenance

System

Hardware

Device Manager

Display Adaptors

Right click & choose Properties

Drivers

Roll Back Driver

[Deadly_Nightshade]

Ok, thanks!

[WITHTEETH]

If you have a nVidia graphic card, with win XP32 bit, try these drivers: 101.02 Forceware Drivers

 

It sounds like a video problem. any other details?

[Deadly_Nightshade]

Well it only seems to freeze at the loading screen, when I attempt to quit via the in-game menu, or when I attempt to access the main menu via the in-game menu. (I can quit using the "qqq" console command...)

Edited April 23, 2007 by Deadly_Nightshade

[Deadly_Nightshade]

My DxDiag...

 

------------------

System Information

------------------

Time of this report: 4/23/2007, 14:23:34

Machine name: SEPHERA

Operating System: Windows XP Home Edition (5.1, Build 2600) Service Pack 2 (2600.xpsp_sp2_gdr.070227-2254)

Language: English (Regional Setting: English)

System Manufacturer: alienware

System Model: D900T

BIOS: Ver 1.00PARTTBL

Processor: Intel

[Walsingham]

Looks to me like your drivers are funted. But I know next to nothing.

[metadigital]

I agree.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Walsh knows next-to-nothing.

Oblivion keeps randomly freezing on loading screens, and almost always freezes the entire system when exiting...

(I just updated my video card driver, could that have caused this? If so, how do I revert tot he older version?)

This is your (very clever) computer telling you to stop playing Oblivion. "

[WITHTEETH]

I would first start with your Graphic driver. Then move down the line.

 

Download the latest Realtek sound drivers if you don't have them already. Oblivion is EXTREMELY sensitive to sounds devices(and codecs).

 

I see you have NERO and Oblivion is extremely senstive to Nero unfortunatly... I would uninstall Nero Completely.

Background processes and codecs can cause severe performance issues, they put additional stress on an already overworked CPU, and they can cause stutter due to adding additional complications to the sound processing, especially if you have onboard audio.

 

So try these two things in case they help:

 

1. Do a clean boot of the computer following the steps from Microsoft.

2. Rule out a codecs issue by seeing whether one of the following helps:

* Nightmare2013's Codec Reset Utility-- Use this one if you prefer having all of your codecs reset to the default official Windows codecs. This is a more minimal approach, but it also may mean needing to reinstall certain programs that depend on extra codecs to run.

* K-Lite Mega Codec Pack-- use this one if you feel you have many programs that depend on extra codecs to run, but would rather replace "intrusive" codecs that may conflict with other programs with more stable versions.

Good luck , Oblivion is buggy period.

[taks]

i'd go straight to the heart of the matter and wrap that sucker back up in its original package and beg to have your money returned. better yet, clear a small area in your room, preferably a room that does not have a flammable floor, such as an unfinished basement, then place the oblivion package, and all of its contents, in the cleared area. pour an accelerant on the pile of garbage you've just created and then touch a lit match, or perhaps one of them long lighters, to the pile. it should light readily. chant any ritualistic verse you can find that thanks the video game gods for not crucifying you for playing as long as you did. it will get better. time heals all wounds.

 

taks

[WITHTEETH]

Analysis: Why the 1.2 patch locks up when you use a door, Black Screen and Looping Sound Upon Activating a Door

Go into My Documents>Oblivion>Click on Oblivion Configuration File> and change iShadowMapResolution to 1024, currently it will be set to 256.

 

This seems to be an interesting fix. Bethesda changed it from 1024 to 256 when they added the SI expansion, but by turing it back , it seems to fix the crashes.

[Bokishi]

LOL yea stop playing oblivion

[kalimeeri]

Analysis: Why the 1.2 patch locks up when you use a door, Black Screen and Looping Sound Upon Activating a Door

Go into My Documents>Oblivion>Click on Oblivion Configuration File> and change iShadowMapResolution to 1024, currently it will be set to 256.

 

This seems to be an interesting fix. Bethesda changed it from 1024 to 256 when they added the SI expansion, but by turing it back , it seems to fix the crashes.

 

Interesting, yes. But it ain't necessarily so--I checked my ini file, and SI hadn't changed the 1024 setting at all. Not sure why, unless it has something to do with my installing the regular 1.2 patch before the expansion. Regardless, I still do see this stutter when entering the gate to Crucible, when the hard drive light is on steady loading the textures. But looping sound does make sense if the computer's working that hard (and it really shouldn't have to). Here's hoping Beth will throw a little fine-tuning in with their next official patch.

[Deadly_Nightshade]

EXECUTIVE SUMMARY

=================

With the 1.2 patch Bethesda decided to change the value of

iShadowMapResolution in the Oblivion.ini file. The new default value for

this variable is 256.

 

By setting this value to 256, Bethesda caused a large number of nVidia

card users to start experiencing random but consistent lockups of their

machines. There are many reports of machines that had been stable for a

year but now easily lockup with the 1.2 patch.

 

The lockup manifests itself as such:

 

Randomly but consistently, WHEN ACTIVATING A DOOR, your entire screen

will go black and you will hear looping sounds. Your machine is hard

locked at this point, no mouse or key combinations work, and your only

option is to reset your PC.

 

This problem occurs for people that are using the latest nVidia drivers

for XP as dictated by Bethesda in their README for the 1.2 patch.

 

For some unknown reason, third party hacked nVidia 8xxx series drivers

appear to prevent machines from locking up.

 

Non-Bethesda affiliated message board users have started telling other

users to install these unsupported drivers on their machines to fix the

issue.

 

However, setting this value back to the original default value of 1024

(from when the game first shipped) allows the game to run stable under

the last official drivers released by nVidia (93.71) for XP.

 

Only Bethesda can explain why this value was changed to 256 with the 1.2

patch. I do not claim that setting this value to 1024 won't cause other

anomalies with the 1.2 patch down the road. However, I do state that it

will stop this specific type of lockup from occurring.

 

There is no need to install unsupported drivers at this time.

 

 

 

BACKGROUND

==========

Before upgrading to the 1.2 patch, I hadn't had a single crash or lockup

of Oblivion in nearly a year.

 

Before installing the 1.2 patch, I backed up my Oblivion.ini file. I had

made a few changes to it that I didn't want to lose. After the install,

I checked to make sure that my changes were still present. Those that

weren't, I reimplemented.

 

I continued to play the 1.2 patch with my old INI file settings and all

was good. After about a week, I heard lots of people on the boards

saying that you should delete your INI and let the game recreate it.

People were talking about a new system Bethesda had implemented that had

objects fading into view rather than popping into view. I decided to

delete my INI.

 

I went away on business.

 

When I got back, I jumped back in and started working on one of my mods.

All of a sudden my machine started locking up when I used doors.

Thinking this was a 1.2 patch upgrade issue, I decided to uninstall

Oblivion and reinstall it. However, the problem continued.

 

I checked the boards and noticed that lots of people were having this

same exact issue. This was very odd because many people were reporting

the same thing: their machines had been rock solid for nearly a year

under 1.1, and now that the 1.2 patch came along, their game constantly

crashed and locked up. Unfortunately, no one seemed to provide any type

of through analysis of the issue. The type of analysis that would be

required for Bethesda to take action.

 

Several people went the way of recommending users install hacked third

party video drivers that would be unsupported by Bethesda and nVidia (in

addition to every video card manufacturer and game producer out there).

These hacked drivers did seem to fix the issue for nearly everyone.

However, I found that to be an unacceptable solution. If the game worked

fine with the 93.71 drivers before, then there was no reason it

shouldn't work with them under 1.2.

 

In addition, no where in Bethesda's README for the 1.2 patch did they

tell people they would need to download and install unsupported hacked

drivers. This clearly meant that Bethesda had the game working in house

on official nVidia drivers.

 

In my mind, this bug clearly existed in the game engine. I set out to

prove it.

 

 

 

ANALYSIS

========

What follows are my notes on my testing procedure along with notes

explaining the logic behind the decisions.

 

 

In order for Bethesda to take this issue seriously, they needed to

understand that it occurs on a vanilla install of Oblivion. So, I did

the following:

 

* Uninstalled Oblivion.

 

* Deleted my MyGames folder.

 

* Installed Oblivion from DVD (US).

 

* Launched Oblivion and set my graphics options and key mappings.

 

* Exited the game.

 

This allowed the game to create the INI file as it originally existed

when the game first shipped. My initial suspicion was that there was a

bug in the new background loading code that was implemented in the 1.2

engine. People had reported that there were massive changes to the INI

file in that section. I wanted a copy of an original shipping INI file

for comparison.

 

* Made a copy of the entire Oblivion directory and my MyGames directory

to another drive letter.

 

* Installed the original version of the Construction Set.

 

* Launched the Construction Set and exited.

 

* Made a copy of the entire Oblivion directory and my MyGames directory

to another drive letter.

 

* Installed the 1.1 patch.

 

* Made a copy of the entire Oblivion directory and my MyGames directory

to another drive letter.

 

* Installed the 1.2 patch.

 

* Made a copy of the entire Oblivion directory to another drive letter.

 

* Made a copy of the MyGames folder to another drive letter - labeled:

MyGames Before Launch.

 

* Launched Oblivion.

 

At this point, my goal was to get a character back to the location where

I first experienced the lockups, the Barren Cave entrance. I wanted a

save game that I could use for testing. I knew that general gameplay

would not be sufficient evidence for Bethesda. I needed to prove that

this was a repeatable issue with a known savegame.

 

* Started a new game. Used the default character looks.

 

* Used tgm and tdetect commands to blow through the tutorial. I turned

tdetect on an off as needed to NPCs would interact with me.

 

* Ran back to Barren Cave and saved.

 

At no time did I make any changes to the INI file. The INI file was the

same INI file that was created by the original launch of the game under

1.0. The only changes that could have been made to the INI file were by

the Construction Set launch or the 1.1 and 1.2 patches.

 

At this point, I tried to duplicate the lockup by running back and forth

through the Barren Cave entrance door for nearly 10 minutes. I couldn't

get the game to lockup. I repeated this two more times. I still couldn't

get the game to lockup.

 

* Exited Oblivion.

 

* Deleted the Oblivion.ini file.

 

* Launched Oblivion and reset the display and key map settings.

 

This caused a new Oblivion.ini to be created.

 

* Exited Oblivion.

 

* Made a copy of the MyGames folder to another drive letter - labeled:

MyGames deleted INI and let it be recreated.

 

* Launched Oblivion.

 

* Loaded the savegame.

 

Once again, I repeatedly ran through the entrance to Barren Cave. At

just over 9 minutes into the first test, the computer locked up. After

resetting the computer, I repeated this process three more times, each

time the computer locked up.

 

I got very scared when two of the door transition autosaves became

corrupted when the game locked up. By default the game does an autosave

when you use a door. Luckily the corruption was limited to the autosave

and deleting the autosave allowed me to continue testing.

 

Being concerned that one of these times the game would trash my

filesystem (when the game locked up), I decided to do all testing from

this point forward with autosaves disabled. I disabled them in the GUI.

 

* I copied the new autosave disabled INI over the one in "MyGames

deleted INI and let it be recreated."

 

* I copied the saved Oblivion.ini file from the "MyGames Before Launch"

folder.

 

I tried two more times to get the game to crash with the original INI

file. I couldn't get it to crash.

 

At this point I developed another theory. I thought the lockup could be

a Havok bug since the lockups seemed to occur after I had hit some of

the vines near the entrance to the Barren Cave.

 

I decided I needed a better place to test this theory because the vines

were too far from the door to really stress test door transversals. I

remembered that the store Red Diamond Jewelry, in the Imperial City

Marketplace, had a Havok bug where the blue shirt next to the door tends

to hang out of the display case and flap in the wind for no apparent

reason. I chose to move my testing to that location to see if the

problem occurred there as well. Since the shirt was closer to the door

than the vines were, I wouldn't have to run as far to hit it and I

should be able to get even more passes through the door per second that

way.

 

* I copied the saved Oblivion.ini file from the "MyGames deleted INI and

let it be recreated" folder.

 

At this point I decided to start actually tracking all my testing in a

spreadsheet. I needed hard numbers and evidence. I knew from previous

tests that the problem took up to 9 minutes before it showed its head. I

decided that I could probably put up with 15 minutes of arm pain per

attempt/test.

 

From this point on, all tests follow these exact steps:

 

1. Boot PC.

 

2. Launch Oblivion via the standard launcher.

 

3. The second the Bethesda video starts to appear on the screen, hit

the Escape key.

 

4. The second the IV movie starts to play hit escape.

 

5. Load the savegame (right in front of the Barren Cave Door).

 

6. Hit the TAB key the second you appear in game.

 

7. Click on the letters SW in the Compass.

 

8. Click in the center of the compass on the second tab.

 

9. Without moving the map, click on the IC Marketplace fast travel

icon.

 

10. The second the scene appears, run up the stairs.

 

11. Take a left under the archway.

 

12. Continue to run straight down the sidewalk past the shops.

 

13. Take a right right before the next archway.

 

14. Stop right in front of the Red Diamond Jewelry Store.

 

15. Face the door.

 

16. Start the stop watch.

 

17. Hit the Autorun key.

 

18. Hit the Use key to open the door.

 

19. Swing the mouse around as fast as possible and go back through the

door.

 

20 Repeat step 19 until the game locks up or 15 minutes have expired on

the stop watch.

 

Using this method, I was able to achieve a door transversal

approximately every two seconds.

 

NOTE: This method put me in front of the shop in the early morning.

Therefore, I was able to go back and forth through the door for between

14:30 and 15:15 minutes before the shopkeeper locked up for the night.

So, although I quote 15 minutes in my analysis, it really just means

"until I couldn't go through the door anymore". That length of time was

close enough to 15 minutes for me (and sometimes it was even over).

 

The first time I ran this test, the game locked up in 42 seconds.

Clearly I could duplicate this at Red Diamond Jewelry.

 

At this point I decided it was time to prove that this problem clearly

didn't exist with the "MyGames Before Launch" INI file.

 

I decided to run 10 tests with each INI file.

 

Here are the results for the MyGames Before Launch INI file:

 

Test Time Approximate

Number of Doors

Gone Through

 

1 15:00 450

2 15:00 450

3 15:00 450

4 15:00 450

5 15:00 450

6 15:00 450

7 15:00 450

8 15:00 450

9 15:00 450

10 15:00 450

 

 

Total Time Tested : 2 hours and 30 minutes

Total Approx. Number of Doors Gone Through : 4500

Number of Lockups : 0

Percent of tests that experienced a lockup : 0%

 

 

Here are the results for the "MyGames deleted INI and let it be

recreated" INI file:

 

 

Test Time Approximate

Number of Doors

Gone Through

 

11 00:42 21

12 00:16 8

13 00:54 27

14 01:53 57

15 01:28 44

16 09:09 275

17 00:23 12

18 00:15 8

19 02:19 70

20 00:22 11

 

 

Total Time Tested : 17 minutes and 41 seconds

Total Approx. Number of Doors Gone Through : 530

Number of Lockups : 10

Percent of tests that experienced a lockup : 100%

Average Numbers of Doors Before a Lockup : 53

 

 

Clearly there was something very bad about the 1.2 created INI file. I

next set out to determine what they could have changed. That lead to

these discoveries about the differences between the INI files.

 

[Water]

bUseObliqueFrustumCulling=1 was removed from the new INI

 

[blurShader]

bUseBlurShader was changed from 1 to 0 in the new INI

 

[backgroundLoad]

bCloneModelsInBackground was removed from the new INI

fBackgroundLoadClonedPerLoop was removed from the new INI

fBackgroundLoadingPerLoop was removed from the new INI

fBackgroundLoadExtraMax was removed from the new INI

fBackgroundLoadExtraMaxFPS was removed from the new INI

fBackgroundLoadExtraMilliseconds was removed from the new INI

fBackgroundLoadExtraMin was removed from the new INI

fBackgroundLoadExtraMinFPS was removed from the new INI

iExterirorPriority=50 was removed from the new INI

 

[Display]

iShadowMapResolution was changed from 1024 to 256 in the new INI

bLODPopActors=0 was added in the new file (matched value in [LOD])

bLODPopItems=0 was added in the new file (matched value in [LOD])

bLODPopObjects=0 was added in the new file (matched value in [LOD])

fGrassEndDistance was added in the new file (matched value in [Grass])

fGrassStartFadeDistance was added in the new file (matched value in [Grass])

 

[LOD]

fLODMultActors was changed from 5 to 10 in the new INI

fLODMultItems was changed from 5 to 10 in the new INI

fLODMultObjects was changed from 5 to 10 in the new INI

 

 

[GamePlay]

STrackLevelUpPath= was changed to point to a Bethesda owned UNC

 

 

 

With this information in hand, I decided to start testing these values

to find out which value was causing the problem. Although I believed the

issue to be the new background loading code. I wanted to stay away from

those for right now since there were so many of them and they might have

strange interactions with each other. I figured it would be better to

test a few of the easier choices:

 

 

Test Time Approximate

Number of Doors

Gone Through

 

Added bUseObliqueFrustumCulling=1

 

21 04:58 149

 

Changed bUseBlurShader from 0 to 1

 

 

22 15:00 450 SUCCESS???

23 6:46 203 NOPE!!!

 

 

 

Test 22 surprised me. I decided to put the "MyGames deleted INI and let it

be recreated" INI file back in place, essentially undoing my changes.

 

By now I was starting to develop carpal tunnel syndrome from the

testing. I decided to try out a new method that would be easier on my

wrist and forearm. I also felt that I could get more door transitions

with this new method and possibly rule out the Havok bug.

 

Rather than putting myself on autorun, I decided to just stand in front

of the door and just turn around fast and activate the door. This way, I

wouldn't be hitting the display case and possibly knocking the shirt out

myself. I was able to achieve about 1.5 door transitions per second

using this method. I performed the following tests using that method.

 

 

Test Time Approximate

Number of Doors

Gone Through

 

24 02:57 118

25 09:25 377

26 02:26 97

27 09:01 361

28 15:00 600 SUCCESS???

29 05:49 175

 

 

Total Time Tested : 44 minutes and 38 seconds

Total Approx. Number of Doors Gone Through : 1785

Number of Lockups : 5

Percent of tests that experienced a lockup : 83.33%

Average Numbers of Doors Before a Lockup : 298

 

 

Test 28 made me feel better about Test 22. It told me that although I

had previously been able to achieve a 100% lockup rate in 15 minutes,

you couldn't guarantee the lockup in 15 minutes. Therefore all successes

in the future must be greeted with skepticism until tested repeatedly

and thoroughly.

 

I was concerned that my times had seemed to jump into the several minute

range before the lockup with this new set of tests. Previously, I had

multiple crashes in under two minutes. The point of this new method was

to save my arm by not having to use it more. I decided to stop using

this new method of testing since I'd end up doing more damage to my arm.

 

I decided to go back to trying INI values. I had already undone all my

previous changes by replacing the INI file.

 

 

Test Time Approximate

Number of Doors

Gone Through

 

Changed iShadowMapResolution back to 1024

 

30 15:00 450

31 15:00 450

32 15:00 450

33 15:00 450

34 15:00 450

35 15:00 450

36 15:00 450

37 15:00 450

38 15:00 450

39 15:00 450

 

 

Total Time Tested : 2 hours and 30 minutes

Total Approx. Number of Doors Gone Through : 4500

Number of Lockups : 0

Percent of tests that experienced a lockup : 0%

 

 

At this point, I was convinced I had found the issue. I decided to stop

and publish my research.

 

 

 

TESTING SUMMARY

===============

 

With iShadowMapResolution set at the new default value of 256:

 

* The game locked up on 17 of 19 tests.

 

* 89.4% lockup rate within 15 minutes of starting the game.

 

* 1 hour 29 minutes and 3 seconds of gameplay were used during the 19 tests.

 

* 3117 doors were gone through (approximately) in the 19 tests.

 

 

 

With iShadowMapResolution set at the original default value of 1024:

 

* The game locked up on 0 of 20 tests.

 

* 0% lockup rate within the first 15 minutes of starting the game.

 

* 5 hours 0 minutes and 0 seconds of gameplay were used during the 20 tests.

 

* 9000 doors were gone through (approximately) in the 20 tests.

 

 

Restoring a single value in the INI file, to the original value it was

set to when the game shipped, caused all of the lockups to cease.

 

 

 

WHAT ABOUT THE HACKED DRIVERS

=============================

 

If you choose to install drivers on your machine that no company in

their right mind will support, then that is up to you.

 

As far as why those drivers fix the issue is well is beyond any of us.

 

Any knowledgeable developer can list numerous reasons why the newer 8xxx

series drivers seem to work as well:

 

* they fixed a bug (this is what everyone wants to believe)

 

or they could have,

 

* made a routine re-entrant that wasn't before

 

* implemented parameter checking to make sure people didn't pass

them bad values

 

The last two would not be considered a bug by anyone that knew how to

write code. If you are a programmer and you tell people how they are

supposed to call your routines and they chose to ignore you, then that

is not your bug.

 

I am not claiming Bethesda did anything wrong. I'm just trying to

express that many things could have changed in the nVidia drivers that

aren't deemed a "bug".

 

 

 

WHAT ABOUT SHIVERING ISLES AND THE NEW 1.2 FORMID BETA PATCH?

=============================================================

Shivering Isles came with its own version of the 1.2 game engine. I

performed no testing on it. Myself and several others have refused to

buy Shivering Isles until this issue has been resolved.

 

I have not tested the 1.2 FormID beta patch either. Bethesda has made no

concession to the fact that they know this bug exists, and they have

made no reference to fixing this issue in their README for the beta

patch. I saw no point in testing something that still isn't finalized

and may still change. I leave that to the reader and Bethesda.

 

 

 

I HAVE A SIMILAR PROBLEM, BUT...

================================

There have been a lot of threads on the support forum where people state

they are experiencing something very similar to this except that they

crash to the desktop (CTD).

 

My game never crashed to the desktop when these lockups occurred. On

numerous occasions, I left my machine run for 3+ hours in the locked up

state. One time, I even left it on for 10+ hours. Every time I came back

to my machine it still had the black screen with looping sound.

 

I have no idea if people that CTD are experiencing this bug or some

other issue with their system.

 

Other people have reported problems exiting Oblivion or saving their

games. Once again, I do not claim or even venture a guess as to whether

or not your problems are related to this.

 

 

 

SO, SHOULD I CHANGE THE VALUE?

==============================

That is entirely up to you. Unless Bethesda comes out and says "Sorry,

we made a mistake, that value should really be 1024 still.", or they

release a new patch that sets it back to 1024, your guess is as good as

mine.

 

I have no idea if putting this value back to the original value will

have any effect on your game down the road.

 

However, I personally prefer changing that value back to what they

originally had it set to rather than installing some kludged drivers

that no one in their right mind would support.

 

As a further argument, Bethesda did not seem to change this value in

INI files that existed when the 1.2 patch was installed. This would

imply that they didn't mean to force this value on everyone.

 

I'm guessing that people getting this value are people that deleted

their INI and let the game recreate it, or people that did fresh

installs and never started the game until they were patched all the way

up.

 

I have been unable to find a way to manipulate the value of that

variable from the GUI. I'm not saying it doesn't exist, just that I

couldn't find it. I'll leave that task up to the reader.