CTDs outta' the blue.

[PillMonster]

This may be of some help.... I recently had same issue with JIP plugin, updating both NVSE and JIP plugin stopped the CTD's. Debug included.

 

 

Could I humbly request a function IsUnderWater run on actors if it's possible please?

 

 

 

Symbol search path is: srv*
Executable search path is:
Windows 7 Version 7601 (Service Pack 1) MP (8 procs) Free x86 compatible
Product: WinNt, suite: SingleUserTS
Machine Name:
Debug session time: Wed Jun 22 06:50:06.000 2016 (GMT+12)
System Uptime: not available
Process Uptime: 0 days 0:01:08.000
................................................................
...................
Loading unloaded module list
..........
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(55c.5d0): Access violation - code c0000005 (first/second chance not available)
eax=00000000 ebx=0018d768 ecx=00000000 edx=00000002 esi=00000002 edi=00000000
eip=7732015d esp=0018d718 ebp=0018d7b4 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00200246
ntdll!ZwWaitForMultipleObjects+0x15:
7732015d 83c404 add esp,4
0:000> !analyze -v
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************

FAULTING_IP:
jip_nvse+21ead
03b71ead ff31 push dword ptr [ecx]

EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 03b71ead (jip_nvse+0x00021ead)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 00000000
Attempt to read from address 00000000

DEFAULT_BUCKET_ID: NULL_POINTER_READ

PROCESS_NAME: FalloutNV.exe

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_PARAMETER1: 00000000

EXCEPTION_PARAMETER2: 00000000

READ_ADDRESS: 00000000

FOLLOWUP_IP:
jip_nvse+21ead
03b71ead ff31 push dword ptr [ecx]

NTGLOBALFLAG: 400

APPLICATION_VERIFIER_FLAGS: 0

FAULTING_THREAD: 000005d0

PRIMARY_PROBLEM_CLASS: NULL_POINTER_READ

BUGCHECK_STR: APPLICATION_FAULT_NULL_POINTER_READ

LAST_CONTROL_TRANSFER: from 005e234b to 03b71ead

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
0018df28 005e234b 03baba04 19f9ab2c 00000000 jip_nvse+0x21ead
0018ee44 005e101f 281e67e0 000026fe 00000000 FalloutNV+0x1e234b
0018f5f4 005e265b 281e67e0 00000000 0b14e050 FalloutNV+0x1e101f
0018f658 005ac29a 281e67e0 00000000 0b14e050 FalloutNV+0x1e265b
0018f688 0060d505 00000000 0b14e050 00000000 FalloutNV+0x1ac29a
0018f6a4 00455518 30008270 00000000 0018f6d4 FalloutNV+0x20d505
0018f6c8 0086f69c 1807f700 0018f6e4 00850d84 FalloutNV+0x55518
0018f6d4 00850d84 15009ee0 0085084b 0018f918 FalloutNV+0x46f69c
0018f6e4 0085086b 15009ee0 00000000 437f0000 FalloutNV+0x450d84
0018f918 008467d3 0937cf3c ffffffff 00000000 FalloutNV+0x45086b
0018f934 007d3548 00000000 1b534098 0018f974 FalloutNV+0x4467d3
0018f948 007ced81 372a31e0 1b28af00 0a3551e0 FalloutNV+0x3d3548
0018f974 0070d36e ffffffff 1726ae58 ad9e7f39 FalloutNV+0x3ced81
0018faf0 0070283b 0018fb04 0086fd81 1807f700 FalloutNV+0x30d36e
0018faf8 0086fd81 1807f700 0018fb5c 0086ecbf FalloutNV+0x30283b
0018fb04 0086ecbf 00000000 00000092 08d16988 FalloutNV+0x46fd81
0018fb5c 0086b3e8 00000000 08b579ed 00000001 FalloutNV+0x46ecbf
0018fee0 73892127 00400000 00000000 0184319c FalloutNV+0x46b3e8
0018ff88 76c6338a fffde000 0018ffd4 773397f2 nvse_steam_loader+0x2127
0018ff94 773397f2 fffde000 775bb403 00000000 kernel32!BaseThreadInitThunk+0xe
0018ffd4 773397c5 00ecc4db fffde000 00000000 ntdll!__RtlUserThreadStart+0x70
0018ffec 00000000 00ecc4db fffde000 00000000 ntdll!_RtlUserThreadStart+0x1b


STACK_COMMAND: ~0s; .ecxr ; kb

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: jip_nvse+21ead

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: jip_nvse

IMAGE_NAME: jip_nvse.dll

DEBUG_FLR_IMAGE_TIMESTAMP: 57583478

FAILURE_BUCKET_ID: NULL_POINTER_READ_c0000005_jip_nvse.dll!Unknown

BUCKET_ID: APPLICATION_FAULT_NULL_POINTER_READ_jip_nvse+21ead

WATSON_STAGEONE_URL: http://watson.microsoft.com/StageOne/FalloutNV_exe/1_4_0_525/4e0d50ed/jip_nvse_dll/32_0_0_0/57583478/c0000005/00021ead.htm?Retriage=1

Followup: MachineOwner
---------

WARNING: Whitespace at end of path element

 

 

 

Hi, I'm using your followers cheat mod (love it btw) and this plugin. After v21 up I get constant CTD's triggered by a Null Pointer reference from JIP NVSE dll.

Could u please have a look at the debug log and maybe suggest a fix.. It's the same instruction every time.

 

Hmm I just noticed v32.10 is out I will try that also..

 

Thanks. :smile:

 

 

 

 

 

 

Edit:

I spoke too soon, Jip_Nvse.dll was to blame for the CTD's after all. I just noticed FNV heap allocation changed to usermode with JIP Plugin v32.10.

It should be left at the default which I think is vmalloc. So that explains all my null pointer exceptions since usermode heap allocations aren't backed by RAM.

 

If the heap manager allocates an address block then later decides to commit and no contiguous memory is found, the pointer will reference a bogus address and trigger an Access Violation. Default WMM setting is best. ;)

 

v32.10

 

 

http://i1294.photobucket.com/albums/b608/pillmonsta1/32.20_zps5uigdv7g.jpg

 

 

 

v32.20

 

http://i1294.photobucket.com/albums/b608/pillmonsta1/32.10_zpsdnlqexej.jpg

Edited June 24, 2016 by PillMonster

[PillMonster]

P.S. On a side note I'm fairly certain Windows Memory Mangler is hampering performance because the amount of RAM used for mapped files is a little extreme. but

I've seen nearly 16GB of standby data made up solely from Fallout New Vegas stuff and Windows won't release it, prob quite awesome if u have 48GB RAM installed. :D

For the rest of us whenever a new area is referenced (or anything really), before it pulled from the drive WMM first has to flush the standby pages because free memory is equal to ZERO..

 

 

I was just talking about this a couple days ago funnily, and today I found an MSDN KB article which kinda confirms it's an issue.. :smile:

 

https://support.microsoft.com/en-nz/kb/976618

Edited June 23, 2016 by PillMonster

[dubiousintent]

@PillMonster: Oh YEAH! :dance: That helps a bunch, at least to my understanding. Let's see if I can break it down for those lurkers who might be having some trouble understanding what you found. (Nice detective work by the way.)

== Wall of simplified technical text coming! ==

First of all, now we can assume that the "Sheson memory patch" is dealing with "dynamic memory management" heap allocation, at least by implication as that is what JIP NVSE is dealing with in that particular problem. [Edit: Hmm. On second thought, that may be an unwarranted assumption. But regardless of the source, the rest of the coverage about memory management heaps is still valid.]

That directly ties in turn to the MSDN article which says (in part and paraphrased) that Windows uses a "demand-based" algorithm for memory management. That means when the current available heap is exhausted (filled up), the Operating System (OS: i.e. "Windows") then adds another heap of the same size for the purpose, until it hits a limitation. There are two kinds of these limitations: "physical RAM", and "virtual address space". ("Virtual address space" fakes the entirety of allocated physical RAM is supposedly available to each program as a single range of addresses, even though in reality it is "chunks" scattered around physical RAM space at different addresses. The actual physical addresses and their contents can be changed by the system as needed without the program knowing about it.) When the physical RAM or "virtual address space" limit is reached the system swaps at least some of the heap information from memory to disk to free up space in memory. Which particular memory of the heap gets swapped is determined by the algorithm, which is balancing efficiency against size, oldest against most recently used, etc. (Heap algorithms are an art in their own right.)

This same "dynamic" behavior also applies to system processes independent of the game (i.e. the system file cache or "page file" among others), so they are in competition for grabbing as much of this limited physical memory space as possible. This can cause memory allocation failures for other system resources.

The virtual address range for 64-bit versions of Windows is typically larger than the physical RAM, so the memory allocations of this type can increase to consume most of physical RAM before hitting that limitation.

Once a limitation is reached, no more heap space can be allocated and swapping to disk has to take place. This swapping is a major slow-down to processing as anything that is not a SSD is thousands of times slower than RAM, and most SSDs are (while fast) even so not as fast as system RAM. (Anyway, you don't want to put your swap file on an SSD, as swapping performs a lot of "disk writes" which are what wears out an expensive SSD quickly.) If a process assumes it can call for more heap allocation without limit, it will cause the system to generate an "out of memory" error, or CTD. Remember that it is competing with system processes for that same memory.

It's that "limitation" that is the issue in question. The MSDN article is acknowledging that there are differences depending upon not only whether the system is 32-bit or 64-bit, but also dependent upon the version of Windows in use. Vista allocated system resources dynamically up to a virtual address range of less than 2GB. Earlier versions had a theoretical memory limit of 1GB, and the virtual address range prevents their exhausting physical RAM.

What PillMonster has seen is that the Windows Memory Manager won't release allocated heap until it hits one of those limitations. In the case of Vista and later versions of Windows, that should be about 2GB if physical RAM is larger. It seems likely that limitation was assumed by the game developers. However, they might not have enforced it in their programming and depended upon the OS to do so. Later versions of Windows appear (from PillMonster's evidence of "nearly 16GB of standby data made up solely from Fallout New Vegas stuff", which tells me he is running a 64-bit system with gobs of RAM) to not be doing so, but to be relying upon the physical RAM limitation instead.

 

[Edit: It occurs to me that there is a "possibility" that enabling the LAA flag for the 4GB patch (i.e. FNV4GB) is having a role is this ignoring of the 2GB virtual address limit. It's directly related to memory management, and not clearly understood in it's side effects when applied retroactively to 32-bit games not developed with it in mind.]

Sidebar: Here the age of the game comes into the picture. "When" a game is developed determines not only "what" hardware is available for developers to work with, but also "what" their target market is expected to have for play in terms of both hardware and OS. So first of all is that FNV is written as a 32-bit game, so that is the primary limiting factor. Next is that at the time of release (19 Oct 2010), the minimum version of Windows required was XP, and the latest listed was Vista (Jan 2007). (Note that Windows 7 was released worldwide on 22 Oct 2009, almost a year before FNV.) The game was in development for 18 months. In addition they were also releasing the game for consoles (XBox 360 and PS3). Consequently, that means the developers were limited to the capabilities of the older systems, which means they couldn't count on the capabilities of Vista unless they coded determination of those capabilities into the game. PillMonster's evidence indicates they did. So, we have to deal with both the older and newer system limitations to virtual addressing, as understood in the 2008-2010 timeframe. This is the very beginning of 64-bit OS memory management transition as well. Lots that was poorly to little known. That MSDN article was last updated in Feb 2014.

Recall back in the beginning I pointed out that when the current heap allocation is exhausted and the program calls for additional, it is given the same amount as originally requested? That has implications for the "heap size" chosen. The larger the requested "heap size", the larger the amount allocated for each call. In addition, a memory allocation request is a "pass/fail" system. You either get all you asked for, or nothing. Ask for heaps of 500MB, and your third call means you have used up 1.5GB of "virtual address memory" for the overall heap allocation. Your 4th request will fail if you only have 2GB of "virtual address memory" because the rest of the game is using at least part of it, causing a swap to disk. (2GB is the default amount of memory allocated to a 32-bit game.) Too large an allocation is inefficient unless it is filled quickly, or it's idle memory. That physical memory space is not available to other processes. Too small a request is also inefficient as it requires more calls which take longer to fulfill. The decision regarding size is something best addressed by the programmer, not the end-user.

-Dubious-

 

[Edit for punctuation and spelling, with some minor clarifications.]

Edited June 24, 2016 by dubiousintent

[KiCHo666]

Wow, thanks for the explanation! :)

My game has been fairly stable with 60 plugins loaded. Only froze 2 times in McCarran interior in 70 hours gameplay so far.

The biggest issue I had was Out of memory which only happened when traveling through/exiting/entering AWOP locations. I assume because they are bigger and have more details that vanilla cells.
I also had both NVSR and NVSE heap replace turned on, so I disabled the NVSR one and I'll see how it will behave now.

Next thing is problem with framedrop after an hour or so of gameplay. It simply drops down to 30-45 and stays there. After saving and restarting the game, it climbs back to 60.

PCB command doesn't help, though.

[dubiousintent]

@KiCHo666: I've been refining it since, right up to spotting your post, so you might want to review it again later if anything wasn't clear.

 

See if the wiki article "FNV Mod Conflict Troubleshooting" can help.

Re: "Out of Memory". See the sub-topic "Issue: CTD without warning, "Out of Memory error", or stops responding" of that article. In particular, "solution-2". Was that what you meant by "PCB command" or were you referring to direct use of the console? Flushing buffers is not an "anytime is as good as another" solution.

 

Re: FPS drop after playing for a while. See the sub-topic "Issue: Game in Slow Motion". See if you can pin down the circumstances in which the slowdown starts more precisely. You may have a similar situation to the Millenia "cheat chest" in Goodsprings, but with a script that isn't shutting down.

 

-Dubious-

[KiCHo666]

Nice! :)

I have almost all tweaks listed there, but I don't have a "slow motion", just the framedrop. The game runs at normal speed, but at lower framerate after a while.

The only script extensive mod I have is Project Nevada, but I believe i5 4690 3,5 - 3,9 GHz should handle it with no problem. Don't have the Millenia weapons.

I use NVSR to get rid of stutters, used the values used in Fear and Loathing, but I still get frame skipping every second (no screen tearing, though).
Hard to describe, but 60 fps I get with NVSR looks smoother than 60 fps I get with Vsync, even with frame skipping.

I believe NVSR was made to fix that microstuttering, but for some reason it doesn't work for me.

[RoyBatterian]

disable iPresentInterval in your Fallout ini and use the video card driver to limit frame rate to 60.7 , removed microstuttering for me but at the cost of some tearing (with NVSR's framemanager turned off). It also solved input lag issues. It's a trade off.

 

As a note, the games have their own heap allocation algo by Bethesda and don't use Microsoft's at all.

 

Kicho: I've been trying to solve the FPS drop thing for some time, can you post me your load order?

[dubiousintent]

@KiCHo666: If Roy hasn't solved the dropping FPS issue, I don't have anything that will help. He's been dealing with FNV issues a lot longer than I have.

 

But we shouldn't hijack this thread onto that issue. It would be better if you created a new post with your LO. You never know who else may have some insight.

 

-Dubious-

[KiCHo666]

True. For OP, here's my load order if it will help, though it's not as large:

 

 

FalloutNV.esm

DeadMoney.esm

HonestHearts.esm

OldWorldBlues.esm

LonesomeRoad.esm

GunRunnersArsenal.esm

YUP - Base Game + All DLC.esm

oHUD.esm

Interior Lighting Overhaul - Core.esm

New Vegas Redesigned 3.esm

ELECTRO-CITY - CompletedWorkorders.esm

AWorldOfPain(Preview).esm

Gomorrah Redesigned v2.esp

Interior Lighting Overhaul - L38PS.esm

DFB - Random Encounters.esm

CCO - Follower Tweaks.esm

Project Nevada - Core.esm

Project Nevada - Equipment.esm

Project Nevada - Rebalance.esp

ELECTRO-CITY - Highways and Byways.esm

DWCNV.esm

Project Nevada - Cyberware.esp

Project Nevada - Extra Options.esm

JIP Selective-Fire.esm

More Perks - DLC.esm

LazarusProject.esm

YUP - NPC Fixes (Base Game + All DLC).esp

The Mod Configuration Menu.esp

The Weapon Mod Menu.esp

CASM with MCM.esp

Interior Lighting Overhaul - Ultimate Edition.esp

Nights are Darker - Ultimate Edition.esp

WeaponModsExpanded.esp

WMX-DLCMerged.esp

Project Nevada - Cyberware Additions.esp

Project Nevada - Rebalance Complete.esp

Project Nevada - All DLC.esp

EVE FNV - ALL DLC.esp

JIP Companions Command & Control.esp

JIP Improved Recipe Menu.esp

JIP Realistic Weapon Overheating.esp

DYNAVISION 3.esp

New Vegas Redesigned 3.esp

WMX-EVE-AllDLCMerged.esp

AWOPLootRobotMerge.esp

WeaponPackMerged.esp

Project Nevada - WMX.esp

Project Nevada - EVE All DLC.esp

ILO - A World of Pain.esp

Spice Of Life Div PN.esp

Casa Madrid Redesigned.esp

AWOP-NVR3.esp

Ragdolls.esp

MiguickFixesMerged.esp

Mojave Travel Reborn.esp

GBMM - Gun Behavior Mod Merge.esp

Conelrad 640-1240.esp

MergedMods.esp

MyMods.esp

MergedPatch.esp

LUASTC.esp

 

This is how LOOT sorted it out.
Just did a few minor tweaks for my custom esps. Also using NVAC and OneTweak.

Except for performance issue and occasional Out of Memory (which, hopefully should now be fixed) the game was very stable for about 80 hours.

RoyBatterian, already tried all that but the screen tearing was dreadful.