Heyas

I'm getting a crash on load all the time, the weOCPS log is telling me it's due to a null pointer reference
Of course, it does not make clear which mod in question is the problem, or at least not that I know of

But maybe someone can debug this for me, so I don't have to pull stuff apart.

Fri Aug 20 18:51:35 2010	OCPS build 2009-03-28 prevented crash at offset 0x00075ec5 (eip: 0x00475ec5, sub_475D80).	NULL-pointer reference!					eax=00000000 ebx=1e374648 ecx=75c6cc69 edx=00b32b80 esi=04272310 edi=08152900 esp=0012ee48 ebp=03660e70Fri Aug 20 18:51:35 2010	OCPS build 2009-03-28 prevented crash at offset 0x00075ec5 (eip: 0x00475ec5, sub_475D80).	NULL-pointer reference!					eax=00000000 ebx=1e374648 ecx=75c6cc69 edx=00b32b80 esi=0428a030 edi=08152b00 esp=0012ee48 ebp=03660e70Fri Aug 20 18:51:35 2010	OCPS build 2009-03-28 prevented crash at offset 0x00075ec5 (eip: 0x00475ec5, sub_475D80).	NULL-pointer reference!					eax=00000000 ebx=1e374648 ecx=75c6cc69 edx=00b32b80 esi=042796b0 edi=091d496c esp=0012ee48 ebp=03660e70

Ok, it crashes with no mods loaded and without OBSE.

I find this hard to believe

Could be a hardware or an Ini problem.

Well, I have totally annihilated my oblivion folder, stripped down to vanilla. The crashes have stopped
I have a strong feeling that I know what the problem is, but the problem has 100% nothing to do with mods.

Share. I think I'm in the same boat with you.

Archive Invalidation!!

I use the BSA alteration method (outdated I know, but nothing else works). After I redid it everything worked fine.
But of course I didn't do this until I totally set off a nuke to my oblivion folder. So... I have an even bigger problem to fix now

BSA redirection should work regardless, unless your game is suffering from interference from UAC, but then I'd expect BSA Alteration to fail too.

Which begs the question - why do you say redirection doesn't work? What symptoms are you seeing?

I tried to use it, however i would always still have stuff with missing textures

When you were having the crashes did you have a User interface replacer also did the crashes occure prior to reaching the Startup Selection screen IE New Load etc.? Reason is that if the XML's get messed or edited by a Mod even disabling the mod will not fix the problem it can actually make the problem worse. What mods and replacers were you using if you remember. Did the problem start after installing or removing a mod?

I didn't even know I was having the crashes at all lol, I use weOCPS so it makes a ding sound when it prevents a crash, but it dings when a save is loading and I guess I never heard it until now because the menu music was louder. I use DarN UI, but I think the issue was that I regened my LOD but I didn't update my BSAs with the new regened stuff so it had a fit. The reason I think this is because I was seeing the LOD models for cities in the city worldspaces themselves.

It's all good now, everything back to normal

I still run weOCPS, not necessarily to play through what would otherwise have been game-ending crashes, but because when the weOCPS bell dings, it indicates that my prevented crash was/is caused by a know issue, and has been documented in the program's log. Not that this info normally helps me much, being a near-total ignoramus when it comes to the inner workings of mods.

My Oblivion install is reasonably stable. weOCPS rarely kicks in. Once every few months seems about average. However, it kicked in last night and again this morning at the same point. Here be details:

We (Vilja and my decrepit avatar) had collected taxes-due from the Roxey Inn and were traveling on foot (a rarity for us) from there to Cheydinhal on a Merchant Guild package delivery assignment. We followed Red Ring Road until it intersected the Blue, which we took and began the trek east toward our destination. We had fought a number of minor encounters while on the Red, and passed several NPCs. Almost immediately after joining the Red we passed a merchant and his guard from PTRoamingNPCs heading west. So far so good. Then, about a minute later, we chanced upon a roaming Argonian Battlemage from the same mod. As we neared him weOCPS dinged.

It happened first last night (real-life time). I decided to exit the game, delete my last several saves, and call it a day. This morning we repeated our steps, ran into the same Argonian (at a slightly different spot in the road due to minor variance between sessions), and again experienced a weOCPS ding.

Here is an excerpt from my weOCPS log, showing both Argonian Battlemage dings:


Notice that they are quite similar, as is proper. I loaded the mod's esp in TES4edit both singly as well as with my entire load-order. Nothing obvious jumps out. With the entire load-order in place, there are a grand total of two Roaming NPC entries with red backgrounds. In both cases the actual mods with red text are not Roaming NPC but either Elsweyr-Anequina (water height variance) or Kvatch Watch Towers (greeting variance). In both cases those variances are overwritten by later loading mods that restore them to "normal".

Admittedly, I've no idea how to look up the two NULL-pointer reference packages seen in the log, or how "MiddleHighProcess::Unk_156" fits in the mix. But this seems like something our more knowledgeable gurus might understand. If so, please chime in with info on how to fix this (via TES4edit if possible since I don't have CS installed).

Speaking of TES4edit, I should point out that applying its two auto-cleaning procedures to PTRoamingNPCs found nothing amiss.

I suppose I should also mention that PTRoamingNPCs is one of my most recent installs. That said, I encounter Roaming NPCs quite often. None has ever before triggered a ewOCPS ding. (Or if so, it was covered by louder environmental sounds.) Can't recall if I have chanced upon that particular Battlemage before. I know I've met at least one of 'em, but not necessarily all.

Thanks in advance!
-Decrepit-

My suggestion: If the weocps bell dings, quit, and continue from the last save. I believe (without tangible proof) that even though the game crash has been saved by weocps, that will eventually catch up to you and screw things royally later. Better to quit at that time and reload from previous save in order to avoid wasting more game time.

Aye, this be my philosophy too, and exactly what I've done thus far. Only, it keeps me from advancing the game. Going to Cheydinhal for a quest turn-in is the next thing I need to do, and every time I try to get there we run into that mounted Argonian and trigger the weOCPS bell ding. I suppose I could try an alternate route, but would rather address the issue head-on if possible.

I did more digging in TES4edit but found nothing obvious. But as stated I'm not even should what I'm look for.

There's a Bashed Patch "Import Names" settings for the mod. It is selected. I thought about rebuilding the Patch without it. But I've used that setting from day-one without issue. Seems odd that after several weeks of reliable service it would act up. Then again, PTRoamingNPCs might be an innocent victim in all this.

-Decrepit-

It's got something to do with an AI pack is about the best I can tell from the output. Did a Google hunt for MiddleHighProcess::Unk_156 and landed on a page with http://www.qwerty-games.com/viewvc/OblivionReborn/obse/obse/GameProcess.h?annotate=1 on it. You may have some luck asking the OBSE gurus if they can help with the bug report you have.

As you already know, I took your advice and most of the above info on the OBSE thread. Things have happened since then. I begin to think I suffer from a much for profound issue. I'm gonna delete my last three saves and load the one made in Weye Manor back when, so far as I know, all was still well. Gonna rest there four game-days. We'll see what happens after that.

For what it's worth, here's a copy of most recent two DINGS:

Fri Apr 29 17:54:24 2011 OCPS build 2009-03-28 prevented crash at offset 0x0024dfb6 (eip: 0x0064dfb6, MiddleHighProcess::Unk_156). NULL-pointer reference (package: 0x206c4d00)!
eax=00000000 ebx=206c4d00 ecx=21fa2b60 edx=0064b040 esi=2271d7c0 edi=21fa2b60 esp=0018f4a0 ebp=206c4d00

Fri Apr 29 18:02:38 2011 OCPS build 2009-03-28 prevented crash at offset 0x0024dfb6 (eip: 0x0064dfb6, MiddleHighProcess::Unk_156). NULL-pointer reference (package: 0x206c4d00)!
eax=00000000 ebx=206c4d00 ecx=21fa1880 edx=0064b040 esi=2271c100 edi=21fa1880 esp=0018f4a0 ebp=206c4d00

This time they came not from the Roaming Battlemage but the merchant with bodyguard I encountered not a minute earlier. The Battlemage was still there but didn't trigger additional DINGs.

I now get consistent black-screen crashes if I walk the opposite direction to avoid the roamers.

War is hell when done right.
---------------------------------------------------------------------------------------------------------------------------
UPDATE:
Deleted saves. Check.
Loaded save in Weye Manor (AFK_Weye). Check.
Rested four game-days. Check.
Walked to the Tiber Septim for a Merchants Guild assignment to Chedinhall. Check.
Walked to A Fighting Chance to sell loot. Check.
Walked to Roxey Inn for tax collection, fighting one bandit and meeting several legionnaires en route. Check.
Walked the Red to its Blue Road intersection, fighting several battles and meeting two legionnaires. Check.

So far so good. But then I was okay this far along before.

Noticed Battlemage Wih-Ju and already reached the Red and had turned south.
Ran to confront him. No ding.
Returned to the intersection and took the Blue.
The merchant's bodyguard galloped by headed east. No ding.
Saw mounted merchant Dandani (sp??) on the road ahead headed west towards me.
Went to meet him.
DING!!!!!!!

Fri Apr 29 20:02:13 2011 OCPS build 2009-03-28 prevented crash at offset 0x0024dfb6 (eip: 0x0064dfb6, MiddleHighProcess::Unk_156). NULL-pointer reference (package: 0x206c4d40)!
eax=00000000 ebx=206c4d40 ecx=21f84210 edx=0064b040 esi=22799d80 edi=21f84210 esp=0018f4a0 ebp=206c4d40

All that for nothing.

One thing I'm still not 100% sure of: is it the NPC, the location, or a mixture thereof? All dings have occurred at very nearly the same spot on the road. Don't know why an area of the map by itself would cause a DING unless it's spawn related. But I waited the requisite time for that to clear itself.

Decrepit...if you are using the 4.2 OSR, you no longer need weOCPS. I quit using after reading a forum, removed it from my folder and started a game. Seemed like it was causing problems rather than fixing. That bell sound could be the culprit, as the same happened to me using the bell sound in Streamline. Try disabling the sound, if that doesn't work, remove weOCPS from OBSE.
However, lemme see your mod PTRoaming? I will open it up and see what is in these NPC for NULL reference and get back...but from the other threads I have seen you in, I am beginning to think the above is true. I had no idea you had weOCPS.

Decrepit: what is your load order up to (2F)?

@Motomatic: This isn't a random sound issue. The debug output from weOCPS was actually useful in this instance. MiddleHighProcess::Unk_156 is part of the code in the game that deals with AI packs and their targets.

I've checked the PTRoaming mod's AI packs, and none of the ones that are user-creatable in the CS have NULL targets. So they can't be the problem. At least not directly.

@Decrepit: What's the formID on the NPC named Dandani?

This gets weirder and weirder.

I've been in contact with Scruggyswuggsy on the OBSE thread. He sent me a special version of the OBSE dll for testing purposes. I loaded my save made just outside Roxey Inn (after having collected taxes there). Proceeded to go through the same steps as always that eventually lead to a bell DING. The difference was that this time I had an OBSE console code I typed every so often. At the end of the session, having typed the code one final type just after experiencing the DING, I exited and saved that OBSE log.

I did this procedure twice.

Turns out PTRoamingNPCs are totally innocent, as I had begun to suspect. Here's the culprit, as shown in both OBSE logs:

MiddleHigh Process Actors:
Actor ref 0018BA9A, base 0018BA88, name Roadsman Fenton
Process has target type Refr (00)
Target is NULL

Roadsman Fenton is a vanilla Legionnaire. His name is attached via Bashed Patch. He patrols (on horse) the Blue Road between Cheydinhal and that ruined fort where Blue intersects Red. I don't recall noticing him during the sessions in question. But I encountered a number of Legionnaires. Several times during my replays I helped a several of them kill the goblin at that fort ruin.

I launched TES4edit and searched for Fenton's ID: 0018BA88. He's affected by Oblivion.esm and the Bashed Patch. That's it. And the Bashed Patch merely gives him an individual name. I looked at his A.I packages and noticed nothing odd. Not that I would, being untutored in that regard.

Scruggsywuggsy suggested I examine any mod affecting legionnaires in the Construction Set. I've never used CS, and in fact don't even have it installed on my primary computer. (By shear coincidence I installed it on my secondary computer yesterday morning, but never messed with it except to ensure it would launch.) I'm not sure what it could tell me that TES4edit doesn't in any case, at least so far as tracking down conflicts.

I do run a goodly number of Legion-centric mods. Almost all been with me since day-one. Most haven't seen updates in quite a while. ImeREAL forts is the only one I can think of that's recently changed. VOILA is the one I'd suspect, if I suspected any of 'em. Looking at it in TES4edit found nothing obvious amiss. Course I could be overlooking something.

Here's where it gets weirder.

Having determined the almost certain source if not cause of my DINGs, I reverted to the standard OBSE dll and loaded my save outside Roxey. I opened the console and used player.moveto to transport myself and Vilja to Fenton (whose PRID is 0018ba9b). He was, as suspected, on the Blue Road, traveling west, not far from where I had been DINGing.

Only, moving to him triggered no DING. Of course the timing was different, since I'd reached him instantly rather than taking the time to walk from Roxey, stopping to fight a few battles en route. In any case I followed Fenton for some time, including his passing the very spot I had DINGed at before. Nothing. All's well!

Okay, thought I. I'll exit and travel to him on foot and see what happens. I did so, repeated steps taken numerous times that consistently led to DINGs. I reached the Blue and headed east on it. Ran into that traveling merchant with guard at the usual spot. Nothing. Continued on. Met Fenton a bit further east. Nothing. Followed him west all the way to the ruined fort, where he turned and headed east again. I kept following. Between east and west, I passed the DING spot twice more with Fenton nearby. Nothing.

I sort of wish I'd kept the specialized dll in-place so I could see if that NULL reference had indeed vanished.

Strange eh?

Don't know what else to do at this stage except load the game outside Roxey and treat it as a regular play-session. If it DINGs, I'm back to pulling out hairs. If it doesn't, I'll continue on to Cheydinhal as originally planned and actually play the game. heh.

Or I might switch back to the special dll just to be on the safe side (assuming I am now safe, that is)

-Decrepit-

PS: Sorry Arthmoor. I forgot to mention that "Dandandi" was my misspelling of one of the Roaming merchants.

None of the AI packs assigned to this NPC have packages that require targets. It would be helpful if the altered DLL you're using could also specify the formID for the current AI pack if that's possible. That would give us something direct to look at so it can be determined if it's something user-correctable.

Aye, wouldn't it.

I should have left well enough alone.

After some debate (while mowing the lawn) I decided I was tired of dealing with this. Should my next launch allow me to pass through that area sans DING (as it had earlier today) I'd count my blessings and just play the game. Alas, it wasn't to be. I loaded my Roxey save, headed to Cheydinhal, and DINGed at that same spot on the Blue Road. I kept going long enough to find Fenton much further east on the road, then exited. Back to studying mods in TES4edit.

-Decrepit-

Well since you at least know which NPC is at fault, you should concentrate any efforts on figuring out if a mod has changed his AI packs.

Worst comes to worst, that NPC could simply get disabled so you can continue on in peace.

Gonna be tricky, since TES4edit shows only one mod altering that particular NPC --- the Bashed Patch. All it does, so far as I can tell, is give him a name as it does with other vanilla legionnaires. Is there stuff TES4edit misses that CS would catch? (Remember that I know absolutely zilch about CS.)

Aye, I've thought on disabling the Legionnaire. Or rather I thought to disable then enable him in hope it might correct something that had somehow become corrupt.

-Decrepit-

Scroll down to the list of his AI packs, and ctrl-click each one. If they're altered, check to see if there are any NULL refs showing. If there are it should be fairly obvious. If none of his listed packs are faulty then the error is coming from something internal to the game that we as modders can't correct for.

And no, Tes4Edit reveals all, and in theory you can build an entire functional mod with it including landscaping and stuff. In fact it's possible tes4edit reveals more than the CS in some cases.

UPDATE:


I did so, though as it turns out I'd already examined those three packs. So far as I can tell, nothing alters them. They are vanilla. It's a mystery.

I followed though with my earlier thought to yet again load that outside-Roxey save, disable/enable Fenton, and proceed on as I had so many times. It worked! At least I got no DING. Admittedly Fenton was now much further east on the Blue than before. But I made sure I found and approached him, and even followed him back to the former DING point. Nothing. That being the case I elected to continue on and am now in a formerly Lost Ayleid Ruin somewhere in the Jeralls.

I still have the outside-Roxey save. At some point curiosity will get the better of me. I'll reinstate the special OBSE dll, load, disable/enable Fenton, proceed, and type that console code when approaching Fenton. That will tell me if my actions resolved the issue (no NULL) or I just got darn lucky and somehow avoided the DING. But that's in the future. For now I just wanna enjoy a few hopefully trouble-free play sessions.

-Decrepit-