Skyrim Memory Patch - fixing ILS, uGrids CTD, freezes

[ENBSeries]

mindw0rk
Try ExpandSystemMemoryX64=false in enblocal.ini

[keithinhanoi]

@mindwOrk:

I've also gotten the MS Visual C++ Runtime Library error window behind Skyrim, fairly often, which either has the message you got:

"This application has requested the Runtime to terminate in an unusual way."

or sometimes this one:

"R6025 - pure vital function call"

That second error is something that has randomly appeared for a good number of Skyrim users, with no clear solution to getting rid of it. However, most people investigating the MSVC++ Runtime errors have found strong evidence its linked to having Dawnguard installed, and can be circumvented by a certain sequence of steps for a particular quest. One person has even linked it to a bad script involved in the Soul Cairn Horse Quest and has posted a fixed script on Nexus - Skyrim.

The problem is that I've been getting this error with a brand new test game character using the console command coc riverwood from the main menu - and sometimes I get the error within 5-10 minutes of starting the tests.

Also, I've only started seeing this error since I installed the Skyrim Memory Patch. I have not done enough testing to show whether ENBoost or anything else is involved, especially because it does not appear consistently and often enough.

Using tools like WhatIsHang, I found out that that this error message window is caused by a 0x40000015 exception error

This error code stands for STATUS_FATAL_APP_EXIT which causes an unhandled runtime exception, which in the case of MSVC++ Runtime calls an abort because of an unimplemented pure virtual call.

Understand that the error is NOT caused by having MS Visual C++ Runtime installed and uninstalling it or updating whatever version of C++ Runtime(s) you have installed won't affect anything.

Simply, the MSVC++ Runtime error message appears because its Window's default method for handling something called a purecall exception error as opposed to a "regular" unhandled exception. An unhandled exception in Skyrim leads to CTD, but with this purecall exception error, MSVC++ Runtime catches it and presents the error message.

With a bit of research you will find that the pure virtual function calls seem to happen due to poor C++ programming - by using a pointer to a previously deleted object or freed memory. Troubleshooting it in Skyrim will be next to impossible because you have to use a debugger, and to do that you need some very important information about how Skyrim was programmed in C++, called symbols to properly debug it. That's nearly the same as having the source code, and of course that would never be shared publicly.

So, knowing all this - if you could follow all my explanation - the best way to troubleshoot the problem is to think about what things you changed in your Skyrim setup just before you started seeing this error window. For me it seems to be related to my use of the Skyrim Memory Patch in conjunction with ENBoost and Stable uGridsToLoad.

Knowing what sheson's code does, and the fact that the SKSE 1.7.0 alpha implementation of his patch doesn't use the third line of fix code, I can pretty safely say that this purecall exception error is not directly caused by patch code changing the allocation size(s) of memory block 1 (and block 2). However, there's still the possibility of an indirect effect due to the initial memory block allocation size(s) being larger.

So, since I also currently have ExpandSystemMemoryX64=true in my enblocal.ini, I'm going to try Boris' suggestion - though I'm really curious why that might help.

@Boris

Can you explain why changing ExpandSystemMemoryX64 to false might help avoid this Visal C++ Runtime error?

I have read through all of your posts about that setting and as I understand it, when ExpandSystemMemoryX64 is set to true it will help reduce memory fragmentation by allowing larger memory address blocks to be allocated in TESV.exe, but works better with x64 systems because in 64-bit systems the 3-4GB memory address space can be accessed.

Also, in a comment on a thread about using ENBoost with Fallout, you said that although ExpandSystemMemoryX64 enabled is useful, it is not as useful as enabling the ENBoost memory manager with ExpandSystemMemoryX64 disabled (not sure if that is true with Skyrim).

Is all of that correct?

[sheson]

I am almost certain any MSVC++ Runtime errors have their root reasons in scripting and not how skyrim deals with memory.

@keithinhanoi
Did you ever get or see reports, if the error can happen when just running ONLY Skyrim+DLC, or lets call it Skyrim Legendary? I am pretty sure I only ever see this error when running additional mods.

I assume you would probably also know the answer to the following question, since you seem to be reading and posting everywhere
In case it happens with only legendary installed, does it also happen when the esm are cleaned?

[ENBSeries]

I don't want to research why this happen, only found that Enchanced Character Edit do not work with skse alpha and ExpandSystemMemoryX64=true, but it works with previous skse and ExpandSystemMemoryX64=true. Just tried to bypass changes of ExpandSystemMemoryX64 for large memory blocks which are patched by skse and ECE works. Anyway, i decided to remove ExpandSystemMemoryX64, because nobody care about largeaddressaware compatibility of their creations, but they blame me.

[keithinhanoi]

I am almost certain any MSVC++ Runtime errors have their root reasons in scripting and not how skyrim deals with memory.

Yeah, I would not be surprised if that was the case. After applying your memory patch fix, and starting to use ENBoost and uGridsToLoad before seeing the error, I've also updated and installed a bunch of mods as part of my preparations for a new play through.

To prove without any doubt that it's not related to third-party (non-Skyrim Legendary edition) mods, I will have to do more testing. I still saw the error during some troubleshooting with just a dozen active mods, but I'll have to try running around in-game with only the official DLCs active. It's a pain though, because if I don't see the error, I don't know how long I should go before I decide Skyrim+Official DLCs doesn't cause it.

As for other people's reports, I'd have to go back and re-read, because I don't remember anyone specifically saying they saw the error in a Skyrim+Official DLCs setup.

A better test would be to make a script that forces the Soul Cairn Horse Quest script problem that blacksupernova made a Nexus Mod fix for, and then see if the MSVC++ Runtime error occurs. Then a positive condition would be identified for the error, and we'd know what to avoid (or fix) in papyrus scripts to avoid the error.

On the question about getting the error with cleaned official .esm plugins, I also don't remember anyone mentioning it, so I'd have to read up on it again.

If I find any more relevant info, I'll post back here, especially if I can confirm that the memory patch fix / ENBoost are not involved - difficult to do because on my machine Skyrim insta-crashes when block 1 hits 256MB, so I have to test with a limited set of mods.

I'm still very curious how the ExpandSystemMemoryX64 setting in enblocal.ini could possibly be related to this...

EDIT:

Oh dear. So Boris -

You mean that ExpandSystemMemoryX64 will be removed from the next ENB Skyrim Series binary release?

I didn't know about the problem with ECE and the SKSE alpha build. Interesting, but yes, also annoying. Anyhow, if ExpandSystemMemoryX64 is removed, then its no longer an issue and you won't get complaints from people about it - I can understand the reasoning there.

Personally, you'll never get any complaints from me - I prefer to understand what all the various settings and options do, and if things don't work for me, it's my problem, not yours.

[number6]

Does anyone know the reason for using Visual Studio 2008 instead of the current 2013 version? I wanted to start doing some development using either one but I am too much of a MS noob to know the differences that matter. Thanks!

[sheson]

@number6

SKSE only supports building on VS2008 due to a language change from C++11.

[AardvarkInDisguise]

Code: Select all

SafeWrite32(0x00687e87+2, 0x00000300);

I was wondering how the 0x00687e87 memory address was found and where the +2 comes from.
Also why doesn't the address change each time TESV.exe is run?

[sheson]

Code: Select all

tesv.exe:00687E87   add     edi, 0x200

the +2 simply is for readability, to keep the original address of the command that is altered.

You can find such stuff with a debugger and setting break points at certain commands addresses, for example the calls to virtual alloc system functions. Then look at the values on the stack for these calls and then back trace to see how those values came to be.

Programs run in a virtual address space, thus virtual addresses are always the same.

[AardvarkInDisguise]

the +2 simply is for readability, to keep the original address of the command that is altered.

You can find such stuff with a debugger and setting break points at certain commands addresses, for example the calls to virtual alloc system functions. Then look at the values on the stack for these calls and then back trace to see how those values came to be.

Programs run in a virtual address space, thus virtual addresses are always the same.

Thanks!
Just to make sure I get this though, is the plus 2 because you are changing the second argument of the add command?