keithinhanoi

Well, it seems I should have taken better notes when hearing the prophesies of Pythia, because I forgot one key word in my interpretation of Boris' comments about the usefulness of ExpandSystemMemoryX64: ExpandSystemMemoryX64 is useful, but in practical terms it is much less useful than if you enable the memory manager with ExpandSystemMemoryX64 disabled. It's fixed in my post now. I'm thinking, what the heck, I'm going to ask Boris what he means by "memory manager." What possible harm could it do?Â

Now see, that's first time I heard that piece of information. So having DisableDriverMemoryManager=false mitigated or reduced the ExpandSystemMemoryX64 functionality? And, then there was the Skyrim patch for PC 1.3.10 which added 4-Gigabyte Tuning (Large Address Aware) support...so, the "expanded memory" setting was always a curious thing to me. The ExpandSystemMemoryX64 has absolutely nothing to do with giving Skyrim, a 32-bit application, access to a full 4GB memory address space. The Skyrim patch which made TESV.exe LAA already did that. Boris has posted the source code for the function, and even though I don't know a lick of C++, it's clear that it makes changes to how memory is allocated. Boris' explanation is that it allows for larger blocks of memory to be allocated - inside TESV.exe's memory address space - thus reducing memory fragmentation, and apparently will "free up more system memory" on x64 (64-bit) systems to make use of the full 4GB available. Despite this, it does not allow TESV.exe to access beyond its 3.1GB cap - that's essentially locked because Windows system processes must take up that last .9GB. So ExpandSystemMemoryX64 is an optimization feature, best used with 64-bit systems, but doesn't give Skyrim any additional access to memory. As for his statement about the ExpandSystemMemoryX64 feature's usefulness when the memory manager is enabled, I believe you've misunderstood it. Since I recently scoured the ENB Forums for any relevant posts by Boris, I can tell you that he has talked about this before - but in even more cryptic English: Using my English language teacher "superpowers", let me translate that to something more easily understood: ExpandSystemMemoryX64 is useful, but in practical terms it is much less useful than if you enable the memory manager with ExpandSystemMemoryX64 disabled. Put another way, if you are using the memory manager, then you don't really need ExpandSystemMemoryX64, because it's not very useful. Add to this that in the same post with the above quote he says very clearly that depending on the game code, enabling ExpandSystemMemoryX64 can cause crashes / freezes. This post was in a thread on Fallout, but it's not difficult to see that this could also apply to Skyrim. So what is the "memory manager" that Boris is talking about? That's a bit more elusive - he could be talking about the main ENBoost feature, when ReduceSystemMemoryUsage is enabled and the enbhost.exe process(es) are used, or he could be referring to his alternative video memory manager that is used when DisableDriverMemoryManager is enabled (set to true). Should I ask? I'm not sure it would help, as he's just thrown out the ExpandSystemMemoryX64 feature.

So, this issue is still smoldering, at least enough for Boris to pull it from his build. Seems rash to me, because the issue if it exists with the SKSE builds only impacted a few people by all accounts. PS keithinhanoi, this is all your fault! :P Yeah, tell me about it. I guess some mysteries in life are meant to be left alone... The thing is where issues with ExpandSystemMemoryX64=true + ECE and the SKSE alpha are concerned, it's not at all clear if sheson's memory patch was also being used, and when trying SKSE 1.6.16 was SSME or a modified skse_steam_loader.dll with the memory patch being used, etc. Even with ExpandSystemMemoryX64 gone or disabled, I still worry that the issues with SKSE 1.7.0 that Boris has mentioned are indicative of some differences in the way it works (even without sheson's patch) that may cause other CTD-prone problems to crop up in future. EDIT: @Nearox: ExpandSystemMemoryX64 doesn't relate to the enbhost.exe feature, just the method of allocating memory address blocks in TESV.exe itself. So the increase of the dynamic memory allocation cap to 128GB is still there - don't worry (yet.)

Well, I'm not sure I deserve thanks, because my last few posts on the ENB Forums seemed to have done more damage than good - even if indirectly. So, I had a chance to ask about the ExpandSystemMemoryX64 setting after Boris suggested disabling it to mindw0rk, who has been getting random Microsoft Visual C++ Runtime error messages. Well, apparently complaints about ExpandSystemMemoryX64=true finally got to him, and he found out that with ExpandSystemMemoryX64 enabled, Enhanced Character Edit does not work with SKSE 1.7.0 installed (but does work with SKSE 1.6.16), so he announced that ExpandSystemMemoryX64 has officially been removed in the latest updated 0.251 binary (along with his great flair for word choice). *sigh* So I guess we'll never really know exactly what ExpandSystemMemoryX64 does, because as of today, it is gone - unless he changes his mind... Sorry, everyone.

Don't know if I can help since I'm worthless testing out any suggestions with my seriously underpowered GPU, but here's a few thoughts: 1. spock, If AutodetectVideoMemorySize=true then the VideoMemorySizeMb is ignored. AutodetectVideoMemorySize will set the Video Memory Size to physical VRAM + shared system RAM allocated by the video card driver. This will be a value similar to what you'd find in the DirectX Diagnostic Tool (dxdiag) information output for your v-card, which will look similar to this: --------------- Display Devices ---------------          Card name: AMD Mobility Radeon HD 5800 Series       Manufacturer: Advanced Micro Devices, Inc.          Chip type: AMD Radeon Graphics Processor (0x68A1)           DAC type: Internal DAC(400MHz)         Device Key: Enum\PCI\VEN_1002&DEV_68A1&SUBSYS_00CC106B&REV_00     Display Memory: 4095 MB   Dedicated Memory: 989 MB      Shared Memory: 3106 MB       Current Mode: 2560 x 1440 (32 bit) (60Hz)What this dxdiag output is telling me is I've got 989MB of VRAM (1GB minus some shared kernel memory address space) and CCC is allocating up to 3106 of system RAM as shared memory (for caching textures, etc.) If I understand it correctly, if you set VideoMemorySizeMb to be the same as your VRAM (or a little less,) then the ENB dynamic memory allocations won't make use of the video driver allocated shared memory, and just use the RAM allocated by the enbhost.exe process(es). This may or may not give better performance and in turn affect the amount of stuttering. So, you could try disabling AutodetectVideoMemorySize, and then "playing" with the VideoMemorySizeMb value. 2. Does the area where you see low FPS, possibly due to foliage, have lots of falling leaf / pineneedle animations? There are .ini settings, and even a lower-resolution texture mod to deal with slowdowns due to those animations. 3. I don't know if it's compatible with your card(s), but you could also try RadeonPro which does have some dynamic framerate control settings. Although its on-screen display features don't work with ENB, most of the features that control / override CCC seem to hook in along with the ENB libraries just fine. But - "Use at your own risk," as the author states.

Wow, I really didn't expect that small storm following my seemingly innocent question about ExpandSystemMemoryX64 set as false in the last few Skyrim ENB binary releases. Still, it shows it would help a lot if we had a much clearer idea what that and the other ENBoost options do, exactly. Personally, I don't get any CTDs at the Skyrim menu with ExpandSystemMemoryX64=true in enblocal.ini and applying sheson's patch via SKSE 1.7.0 alpha with DefaultHeapInitialAllocMB=768 / ScrapHeapSizeMB=256 in skse.ini. However, I can't say whether ExpandSystemMemoryX64=true versus false definitively leads to CTDs an hour into a game or not simply because I've not had enough chances to play more than an hour solid (busy adult-father-working real life.) Even if I did get CTDs that far into my game, I'd need to examine mini-crashdumps and other hard data before I could agree that this one setting is the culprit. Anyhow, after another exhaustive set of keyword searches through the ENB Forums, I've found some very interesting tidbits from Boris that has changed the picture I've put together of what the [MEMORY] settings do. Because of this, I've decided it would be better to post my understanding of each setting, one at a time, in a thread on the ENB Forums, and (politely) ask Boris to say either "yes, it works like that," or "no, here's what it actually does..." Stay tuned....

By the way, to see what the actual allocations are for the two block sizes, go no further than the fifth line in .log file from sheson's Memory Block Log: logging of blocks enabled logging max values only Timer disabled Block1 Block2 256MB 256MB   <-- Your block allocations right here 85 8 85 8 85 9 85 10If it's not what you expected to see, then you've very likely not set things up right (as Domiel discovered.)

Sorry that this is a bit late to be helpful - but for future information: After extensive research on the topic, including aritcles / posts by people who work for Microsoft, I found that in Windows 7, your pagefile only gets used if your total memory commit charge limit value exceeds your physical RAM value. The total commit charge is your physical RAM + your maximum pagefile size, and is basically the maximum memory space that you are allowing Windows to use. Utilities such as Process Explorer or it's cousin Process Hacker (highly recommended) allow you to check on your current commit charge (the memory Windows + all your apps, etc. are currently using,) and your peak commit charge (the maximum memory that has been used since you logged in.) It's important to note that in x86 (32-bit) your physical RAM addressing is capped at 4GB, so you rally only have an opportunity to save space (and supposedly wear) on your SSD if you're running x64 (64-bit). From this explanation, it's easy to believe that if your peak commit charge never exceeds your available RAM, then you can just turn off your pagefile. Wrong. This article, despite being written in 2009, is still very true of Windows 7 even now. It explains that turning off your pagefile can cause Windows to suddenly run out of memory if you have enough applications running to use up all your RAM, but more importantly quite a few utilities and applications are built with the assumption that Windows is using a pagefile as part of it's Virtual Memory management, and won't work with the pagefile turned off. A lot of information in that article about the relationship between RAM & the pagefile comes from blog articles by Mark Russinivich, who is the author of the awsome Sysinternals Tools (including VMMap, which sheson used when discovering the Skyrim Memory Patch 3.0). After reading through all of Mark's articles on the subject, I found out that as long as you can guarantee your total commit value won't exceed physical RAM, then you can set the pagefile to something quite small, like 64MB - but you also need to turn off the Windows crashdump feature, which is actually a good idea for an SSD, because they are huge, and can eat up drive space very quickly. I have used a custom pagefile setting with an Initial size of 64MB and Maximum of 512MB for over two years now, ever since I upgraded my RAM to 16GB. I upgraded to 32GB of RAM last November, and in all two years I have NEVER seen my pagefile get any larger than the initial 64MB. So, DoYouEvenModBro, if you've got 8GB and are running 64-bit, then I'd suggest monitoring your peak commit charge when playing Skyrim for a few sessions, and if it doesn't come close to 8GB, then consider setting your pagefile to be smaller, as I've done. I hope that helps to explain things a bit better and put a final nail in the coffin of the turn off your pagefile tweak.

Well, that was easy. Boris has changed ExpandSystemMemoryX64 to false in the included enblocal.ini because it conflicts with some anti-virus software, leading people to complain to him too much! Read his funny reply here. Moral of story - If you've read up everywhere else and haven't found a convincing answer, just ask the source. Issues with anti-virus software has been duly noted in my detailed explanation of the ENBoost [Memory] settings. Still not feeling they're finished, but if someone asks, I'll post them here for review.

Yeah, I completely agree. But what seems to happen is due to language limitations, the initial explanations for any added .ini settings have been quite brief and not always self-evident. Then people try setting them one way or another, come back, and say it's not working, and Boris gives suggestions based on their particular setup and problem. So you have to build a picture, as it were, of what the setting does, based on explanations of XXX setting will help users with a ZZZ type of setup. Keep in mind that a big part of the problem here, also, is that Boris has added settings to help users with different systems, but he has no way to set if those settings help on his own system. My approach to these kinds of settings is to know that they definitely do something specific, and I just need to understand what that is. If I know what each setting or switch does, I can decide whether it will help me with my particular system. So in this case, I've been reverse-engineering the explanations. Then, if I'm quite sure about what one of them does, but need confirmation, I've decided to just ask. This worked great, for example, with getting absolute confirmation from Boris about the AutodetectVideoMemorySize switch added with 0.243 - where it seemed that setting it to true would mean that the VideoMemorySizeMb value would be ignored. So I asked and he confirmed it, in no uncertain language. He also explained in a follow up post how AutodetectVideoMemorySize determines the video memory size, though the exact way it's implemented is a bit more elusive to me, and I think I should ask him after I've tested my theory that it is based on the shared video memory value as given in Windows' DirectX Diagnostic (dxdiag) tool report. Anyhow, I strongly feel that the enblocal.ini settings need much better clarification since ENBoost was thrown back into the limelight following sheson's memory patch fix. However I can help towards that end, I will. But, I just haven't put it all together and posted it in one place because I don't feel it's 100% accurate yet.

IncreaseUserVA can't and shouldn't be used with 64-bit Windows, because it can already give 4GB of memory (called user-mode virtual address space) to programs. It's only needed for when you're try to use programs that want more than the default 2GB limit that 32-bit Windows allows. By setting it to 3000, you've just allowed Windows to give 3000MB to any program, and reduced the amount of memory the Windows system can use from it's default 2GB to 1096MB. Remember that Windows 7 x86 (32-bit) is limited to using a maximum of 4GB of RAM. Reducing the memory for the Windows system is fine as long as you aren't using any 32-bit drivers which assume they can use the normal 2GB of memory for the system, and then find out they can't. This can cause all kinds of problems, even errors when writing files, such as was explained here. Another important thing to keep in mind is that some of the 1096MB you're leaving for windows may be used for something called hardware mapping, which is system RAM used to match memory on hardware devices, including your videocard. If you've got only 4GB of RAM, that hardware mapping has to happen there, typically around 128-256MB for video cards, and with other hardware devices can reach a total of 512-768MB, all taken away from the memory you've allowed Windows. If you've got more than 4GB of RAM, then hardware can be remapped above the 4GB mark, and so all of the first 4GB will be available to Windows + your program(s). Finally, increasing the UserVA value (and thus lowering the Windows system VA) can cause more paging - using your page file - which means using your HDD/SDD as a cache to extend your available memory through the use of virtual memory. This can slow things down considerably, and translate to lower performance in your game. To avoid this, you should try to make sure all unnecessary processes are disabled or not running while playing Skyrim. So I suggest using caution with IncreaseUserVA, and if you notice any strange behavior with your system or things not working as expected, try reverting it with cmd > bcdedit /deletevalue increaseuserva. Bottom line? If you're having to use IncreaseUserVA, then if at all possible, upgrade to 64-bit Windows, and invest in some more RAM!

Heads up everyone - Gopher has finally made one of his wonderfully informative videos . He also explains the use of sheson's Memory Block Log SKSE plugin tool to determine what memory block allocations you should use. Especially recommended for those who have trouble reading ;p - Have a look!

Glad to hear it! I saw you also posted in the comments thread of sheson's memory block logger "mod" on Nexus, so I replied with the same advice for anyone coming through. The file extension thing is a very common "gotcha" for people, along with confusion on the location of .ini files. I really don't understand why SKSE or other software which have .ini options don't just include an empty .ini file in the right location of the install archive, which can just be opened up and added to if the user so wishes.

-forcesteamloader is not needed in order for the memory patch to load. Since the modified version of the skse_steam_loader.dll with the hardcoded increase in size of block 1 works for you, then there's just a few possible reasons why the .ini based skse_steam_loader.dll or the SKSE alpha build aren't seeing your .ini settings: 1. The file extension is wrong. With a Windows Explorer window open, choose Tools -> folder options, and make sure Hide extensions... is NOT ticked. Then check if skse.ini is actually named skse.ini.txt and if yes, rename it to remove .txt so the name is just skse.ini and click [yes] to the warning about changing the file extension. 2. The skse.ini is in the wrong place. Make sure it is located in ... \skyrim\Data\SKSE, and not in any other location. 3. The wrong setting labels in the text of skse.ini are being used. They are different depending on which variation of sheson's patch you're using. Check on #1 and #2, and if those don't work, let's see the contents of skse.ini for whichever variation of sheson's patch you're currently trying to get to work.

I've tried out the new SKSE 1.7.0 alpha build. Without any changes to skse.ini, both memory block 1 & 2 show as 256MB in VMMap and also using sheson's Memory Blocks Log plugin. Then I added these lines to the skse.ini: [Memory] DefaultHeapInitialAllocMB=256 ScrapHeapSizeMB=256 Skyrim does NOT start, at all - a bit of a problem! Looking at the source code, I can see right away that there is no trap to prevent users from setting both memory blocks too low. By setting DefaultHeapInitialAllocMB to 256, that means I have set memory block 1 to zero as we would see it in VMMap. As thalixte has pointed out, there are some clues in the source code as to why the default value set for block 1 in TESV.exe is 512MB, while we only see 256MB being used in VMMap: // in megabytes, -256 depending on bInitiallyLoadAllClips:Animation <snip> _MESSAGE("default heap = %dMB (effective %dMB if not preloading animations)", defaultHeapInitialAllocMB, defaultHeapInitialAllocMB - 0x100);This must mean all 512MB is allocated if animations are preloaded, but that must not normally happen. I've never seen this bInitiallyLoadAllClips setting - is that something that would be in skyrim.ini or skyrimprefs.ini? Anyhow, continuing with my tests - Since clearly the skse.ini setting needs to be 256MB higher than what you want to see in VMMap, the next .ini settings I tried were: [Memory] DefaultHeapInitialAllocMB=768 ScrapHeapSizeMB=256 In VMMap and in the Memory Blocks Log, I confirmed that the allocations appear as 512MB & 256MB. To answer tony971's question, in my last test, I changed the .ini settings to: [Memory] defaultHeapInitialAllocMB=1024 scrapHeapSizeMB=512 In VMMap and the Memory Blocks Log, the block 1 & 2 allocations were 768MB & 512MB. I hope that clears things up. Some final thoughts - 1. I need to let the SKSE authors know as soon as possible about needing to prevent users from setting the two allocations under the vanilla defaults. 2. I don't see the third part of sheson's patch in the source code file I looked at, named Hooks_Memory.cpp. Maybe it's elsewhere - but I'm curious to know if they implemented that as well. Sheson has explained it as an important part of his original idea for the memory allocation fix, and it should probably still be left as part of the patch. 3. I really want to know what this bInitiallyLoadAllClips setting is, and the animation preloading that supposedly would take up the other 256MB of block 1 that we never see represented in VMMap. Is that something we want to be doing? 4. Before dropping in the new SKSE alpha build I had been doing tests with SSME in trying to figure out a problem with reproducible CTDs when loading some earlier savegames. When I removed SSME's .dll, and used the new SKSE build's memory patch - I was not able to reproduce any CTDs when loading any savegames whatsoever. This is an interesting development because absolutely nothing else was changed between the last CTD I got 20 minutes prior to my tests with the new SKSE build.

If you look at sheson's original code, it also shows a vanilla allocation of 512MB (0x00000200) for block 1. The reason why everyone referred to the default (vanilla) allocation for block 1 being 256MB is that when you use VMMap to look at private memory address allocations, there are two 256MB address blocks. Sheson's original code increases the actual allocation for block1 with a value of 768MB (0x00000300), but in VMMap, it shows up as 512MB. This question was asked early on in the ENB thread, and the explanation was something to the effect of this is just the way TESV.exe sets up the allocations. Bottom line, the SKSE implementation is not doing anything different.

The new SKSE v1.7.0 alpha build has been posted. At the bottom of the whatsnew list: - thanks to sheson: added configuration of some initial pool sizes     [Memory]     DefaultHeapInitialAllocMB= <default heap initial allocation size in megabytes, vanilla size is 512>     ScrapHeapSizeMB= <scrap heap size in megabytes, vanilla size is 256> Joy!

@mothergoose A few considerations / questions: 1. Can you reproduce the crash when entering Whiterun? If so, you could turn on SKSE's mini crash dump feature, and though the output is something you'd help from others, it may present some clues as to why you're seeing a crash there. It can't hurt anyhow. It's explained in the original OP on ENB forums, but if you need steps spelled out, just let me know. Note you'll only get a crashdump if the game CTDs (won't work when it freezes.) 2. Also if the crash entering WR is reprodicable, get a screenshot in VMMap showing the 2 block sizes just before you enter. It's remotely possible that your usage of block #1 is nearing 512MB, though from your screenshot from your magic casting test, I think 512MB is plenty. 3. Your Skyrim/Prefs .ini files look like default "ultra" settings - is that right? If so, they should not be causing any CTDs on their own. 4. SKSE plugin load order can't be changed (at present,) but I see you're using the Player Physics mod by AltimorFP. I don't know much about it other than it only works well if you can maintain 60FPS at all times. Perhaps try disabling it and test some more? 5. enblocal.ini looks fine, though as I understand it AutodetectVideoMemorySize=true will overwrite your VideoMemorySizeMb=1920 line to make the size an even 2048MB. I assume you set 1920MB for some "breathing" room in your vid RAM usage. If ENB hasn't capped it lower than 2048, it means you could possibly get a crash if there's a spike to completely fill your vid RAM. If anyone else here knows otherwise, please correct me on this. To play it safe, just change AutodetectVideoMemorySize= to false. 6. There's a new v3 beta of SkyFalls + SkyMills available. Although he's calling it a beta, the reports are coming in from people that there's not seeing CTDs anymore as they did with v2, and in my use (along with sheson's patch to make block 1 = 512MB) I've had zero problems as far as I'm aware. Just don't install the optional LOD files - they still need some kinks worked out. EDIT: Also, just try disabling it of course!

On the ENB forum thread, somebody has pointed out a new development: SSME - Skyrim Startup Memory Editor which uses a new approach to injecting sheson's patches. Basically it presents itself as one of the Direct3D 9 Extensions dynamic libraries (3dx9_42.dll) for Skyrim to load at launch, when the memory block allocation size patches are injected. Great idea, because it doesn't require any modification of an SKSE library (which would keep with their wishes.) However, he's running into snags, and it's not working for everybody yet. It would be really great if he'd share his source code for those in the know to take a look and help out. EDIT: I and another user asked about source code, and it turns out the library was written in assembly. Anyone here familiar with assembly language? EDIT 2: I just learned that the author of SSME also created a quite comprehensive solution to crashes in Fallout NV - NVAC - New Vegas Anti Crash, available on Nexus FNV. The number of endorsements for NVAC and a quick skim through the comments thread quickly proves to me that s/he really knows her/his stuff when it comes to assembly language.

I'm definitely not saying "it's your fault." But before deciding any "fault" if we could even call it that, let's make sure the patched .dll is doing what it's supposed to do. There's only one way to be absolutely 100% sure, and that's to use VMMap to look at the Private Data memory allocations in TESV.exe. As Nearox explained, click the Size header of the bottom table pane to sort the list by size, scroll to the top of the table list in that pane so that you see the largest Size entries, and you should see this: The red arrow points to where you should click to sort by Size, and the numbers circled in blue are what we're looking for. As for the alt-tab out of Skyrim problems, you can try a couple of things: 1. Make Skyrim not pause when in the background: in skyrim.ini under [General] add the linebAlwaysActive=1 or... 2. Change to full screen borderless window mode: in enblocal.ini, under [WINDOW] set:ForceBorderless=true ForceBorderlessFullscreen=true in skyrim.ini, under [Display] set:bFull Screen=0 And if those don't work, there are some SKSE plugins which could help. Once it's confirmed that the patched .dll is working for you, then we could look at other elements in the equation.

@mothergoose729 Could you post a screen of VMMap after you've been around in a new game for some minutes? Also, if you you add: [Debug] WriteMinidumps=1 to your SKSE.ini, then when Skyrim CTDs, you'll get a dmp file in \Users\YOURACCOUNT\Documents\my games\skyrim\SKSE\Crashdumps. Make a .zip archive of this dump file, and upload it to the OSR Online crash dump analysis webpage that sheson suggests, here. Then, copy and paste the resulting report text to pastebin and let us know that link. On sheson's OP thread, he's been able to give people some clues about what's going on from their crash dump. We can't know exactly what happens in Skyrim, because we don't have Bethesda's symbols used to compile their source code, but there are other things in the crash dump report that can help. I myself have seen the memory patch get rid of CTDs that would happen with a brand new game in certain trouble spots, but I'm still getting random freezes (and one CTD,) but that's mostly while using speedmult 1500 for stress testing.

Just a quick report on my findings so far - I tried using windowed mode, without any of the SKSE-based plugins that are supposed to help when doing that, so I could watch things in VMMap & Process Hacker. This did not work well, because #1 VMMap does not refresh the numbers on a consistent & regular basis, so I still had to tab out to hit F5 to refresh. #2 problem was that (on my system) in windowed mode loading of my game or interior / exterior cell change requiring a loading screen took 1-2 minutes. Changing back to full screen fixed this, but I worried that having to tab out of Skyrim would affect the numbers shown in VMMap (because the game effectively pauses when tabbed out.) I notice that you can view memory address allocations in Process Hacker, but it only shows commit values (not too bad, because usually the same as private bytes), but more importantly it did not group all the children of the 2nd block, so I needed to keep VMMap open to cross check on the addresses of the 2nd blocks, er, um, children. Going to some memory intensive places suggested by sheson and others, I saw peak usage at roughly 340MB/135MB, but I just don't trust those numbers without having some kind of log. After hearing back from sheson, I am now going to try to find some way to log the private byte / commit usage for the two memory blocks that this patch affects. I also did experience a CTD after 1 minute at speedmult 1500, but then I couldn't check the final memory block usage before crashing because of the problem with infrequent refresh in VNMap, and hitting refresh after TESV.exe has died give you "PID no longer available" type error (as to be expected.) Nonetheless, as I mentioned before, in all the places where I've previous seen consistent crashes, I was still able to sail right through, or open up inventory, etc. menus without incident. Anyhow, when this CTD happened, I had the SKSE minidump feature turned on, so I uploaded it to the OSR Online site recommended by sheson, but the fault listed did not match the one in sheson's explanation in his ENB forum post. As much as I could tell from the analysis, I seems that some memory address was trying to be written to that wasn't available or protected. This may have been TESV.exe trying to start a new allocation block because my first 512MB got full, but with the values I was seeing in VMMap, I doubt it. To be honest, the CTD I saw could be related to using not the best settings in enblocal.ini, because I prior to this memory patch, I had been trying to work through my CTD problems without the ENB memory boost features, as I never saw my TESV.exe memory usage go much over 2GB. I can certainly post all my .ini's, modlist, etc. and the crashdump on pastebin if it interests anyone - but this is by no means a plea for tech support! My system specs are in my sig for reference.

@SSL - The first patched .dll I downloaded was from this Reddit thread. I have since started using a compiled .dll with the adjustable block allocation .ini settings by Daetarek (in the original ENB Forums thread.) The first link to a pre-compiled Daetarek version forced me to get a LL account, but it's now available from many sources (such as Neo's variation with the .ini setting name changes, and also Phinix has posted one on his ENB page on Nexus.) There's even another variation on the original ENB thread from a "Tase" who has patched the SKSE_loaded executable to load a custom .dll with Sheson's code, all of which allows you to circumvent the need to run Steam. Not something I need since I've got enough system RAM to leave it running in the background (and besides, I use Process Lasso to give SKSE.exe and enbhost.exe multimedia app priority status). It's great that the source code has been shared, and very very well explained, but since it's out "in the wild" there are now dozens of sources for patched .dll, not all guaranteed to work (see #1 of my four questions.) I really hope the SKSE team or Boris takes this up to include in their next release, so this situation stabilizes. For now, however, I expect there still to be a bit of a "voodoo" aspect to the reports of how well the patched .dll works from quite a few people (present company excluded!) @z929669: I will have to see if running in windowed mod will change the private usage levels of the two blocks, because that how I usually run when I want to watch memory usage beyond simple on-screen stats (say, using Process Hacker.) If the memory usage is the same, then you don't have to worry about tabbing-out. Still, peaks in usage could happen suddenly and briefly and you may miss them. It's these sudden jumps that lead to Skyrim choking in the first place, from what I can tell. If I was using audio recording equipment I'd have a dB metre which displays the highest peak, and then set levels such that I've got some additional headroom above that.