Requesting assistance

[Jindale]

Greetings, some time lurker, first time poster.

 

I was wondering if anyone could offer assistance in sorting out some stability and possible critical errors. Some trivial information perharps, but all executables like TESV, enbhost, skyrim launcher etc. in the install root are set to admin rights, as well as is the MO. I am using only one profile so Overwrite conflicts don't propably cause an issue, but ever since enabling all possible ESPs and ESMs from mod resources, I have been having this one long error lingering in MO.

 

I put on my big boy pants and created the modwatch in advance: https://modwat.ch/u/Markkuboi/plugins

For the sake of a cleaner post, I decided to leave the error message at the very end. Thank you for your time for even reading this post, and best regards.

 

DEBUG (21:18:45.0914): createfile w: C:\Program Files (x86)\Steam\steamapps\common\Skyrim\Data\Dragonborn.esm -> C:\Program Files (x86)\Steam\steamapps\common\Skyrim\!TOOLS\Mod Organizer\overwrite\Dragonborn.esm (80000000 - 3) = 000009AC (0)
DEBUG (21:18:45.0915): createfile w: C:\Program Files (x86)\Steam\steamapps\common\Skyrim\Data\SkyUI.esp -> C:\Program Files (x86)\Steam\steamapps\common\Skyrim\!TOOLS\Mod Organizer\mods\SkyUI\SkyUI.esp (80000000 - 3) = 00000A20 (0)
INFO (21:18:45.0915): Windows Exception (c0000005). Last hooked call: void *__stdcall CreateFileW_rep(const wchar_t *,unsigned long,unsigned long,struct _SECURITY_ATTRIBUTES *,unsigned long,unsigned long,void *)
DEBUG (21:18:45.0915): createfile w: C:\Program Files (x86)\Steam\steamapps\common\Skyrim\Data\Dawnguard.esm -> C:\Program Files (x86)\Steam\steamapps\common\Skyrim\!TOOLS\Mod Organizer\overwrite\Dawnguard.esm (80000000 - 3) = 00000A30 (0)
ERROR (21:18:45.0915): This is a critical error, the application will probably crash now.
INFO (21:18:45.0915): Windows Exception (c0000005). Last hooked call: void *__stdcall CreateFileW_rep(const wchar_t *,unsigned long,unsigned long,struct _SECURITY_ATTRIBUTES *,unsigned long,unsigned long,void *)
INFO (21:18:45.0915): Windows Exception (c0000005). Last hooked call: void *__stdcall CreateFileW_rep(const wchar_t *,unsigned long,unsigned long,struct _SECURITY_ATTRIBUTES *,unsigned long,unsigned long,void *)
INFO (21:18:45.0915): Windows Exception (c0000005). Last hooked call: void *__stdcall CreateFileW_rep(const wchar_t *,unsigned long,unsigned long,struct _SECURITY_ATTRIBUTES *,unsigned long,unsigned long,void *)
ERROR (21:18:45.0916): This is a critical error, the application will probably crash now.
DEBUG (21:18:45.0915): createfile w: C:\Program Files (x86)\Steam\steamapps\common\Skyrim\Data\ApachiiHair.esm -> C:\Program Files (x86)\Steam\steamapps\common\Skyrim\!TOOLS\Mod Organizer\mods\ApachiiSkyHair v 1 6 Full\ApachiiHair.esm (80000000 - 3) = 00000A24 (0)

[donttouchmethere]

12 minutes ago, Markkuboi said:

but all executables like TESV, enbhost, skyrim launcher etc. in the install root are set to admin rights, as well as is the MO.

You heard that already I guess:

DON'T INSTALL in C:\Program Files

even just C:\ would have been better

 

if you give admin rights you need to give those to all skyrim/modding related folders too

also check your virus scanner and set skyrim/modding folders as expection

 

still your issue can be from something MO related

lets wait for the MO pros^^

[yatol]

36 minutes ago, Markkuboi said:

 

 

I was wondering if anyone could offer assistance in sorting out some stability and possible critical errors. Some trivial information perharps

INFO (21:18:45.0915): Windows Exception (c0000005
ERROR (21:18:45.0915): This is a critical error, the application will probably crash now.
INFO (21:18:45.0915): Windows Exception (c0000005).
INFO (21:18:45.0915): Windows Exception (c0000005).
INFO (21:18:45.0915): Windows Exception (c0000005).

c005, it's ram ctd

[Grey Cloud]

Wow, that is so fucking helpful.

 

 

[Jindale]

So basically, I'd have to move all the files to another location for maximum stability? I know it might be besides the point and bit deflective, I assure you it's not, but I personally haven't had problems with the default location. Will move if it's mandatory though.

 

But inherently, I am trying to figure out is there anything particularly messed up with my load order or the order in what MO uses the resources, or the configuration settings to that regard as well. The error messages popped up only this evening, after tinkering with the Optional/Available ESP.

[RW311]

 c0000005 error, accessed reserved memory that is reserved for you to access it when something went wrong so something worse didn't go wrong.

 

If the program does not need to run in program files move it, registry errors often cause this access violation as often as actual application faults. Doesn't mean moving it out of prog files will solve the problem but there is no good end to having this program in there. If you had a power fault or reboot while this application was running in program files you end up with a lot more screwed up registry entries than just having it loose in c drive or somewhere else.

[Jindale]

14 minutes ago, RW311 said:

 c0000005 error, accessed reserved memory that is reserved for you to access it when something went wrong so something worse didn't go wrong.

 

If the program does not need to run in program files move it, registry errors often cause this access violation as often as actual application faults. Doesn't mean moving it out of prog files will solve the problem but there is no good end to having this program in there. If you had a power fault or reboot while this application was running in program files you end up with a lot more screwed up registry entries than just having it loose in c drive or somewhere else.

So can I just move the entire installation folder as-is to another location safely, and then just reconfiguring to MO where the executables are, or do I absolutely have to redo it all?

[RW311]

This is what I find, another one suggested installing it to the new directory then copying the files. I don't use it so I can't confirm anything...

 

https://forums.nexusmods.com/index.php?/topic/1974769-can-i-move-mod-organizer-folder-to-another-directory/

[Jindale]

Thanks regardless. Trying the copying of all directories to the drive root to see if this works. Would still need help with is there anything particular wrong with my load orders and resource orders, so far unchanged from the list I posted in op.

 

Well bummer. So far all I get is Win7 telling me all paths are too long, and I am very uncertain about renaming the files since the mods may need their original names to function properly. And yes I am trying to move the entire installation with all the mods/tools/whatever, instead of leaving just the game to Program Files.

[yatol]

3 hours ago, Grey Cloud said:

Wow, that is so fucking helpful.

 

 

Wow, that is so fucking helpful

 

you have nothing to say about the blabla about moving around skyrim folder? what is that supposed to do about ram ctd^^

 

[RW311]

2 hours ago, Markkuboi said:

Thanks regardless. Trying the copying of all directories to the drive root to see if this works. Would still need help with is there anything particular wrong with my load orders and resource orders, so far unchanged from the list I posted in op.

 

Well bummer. So far all I get is Win7 telling me all paths are too long, and I am very uncertain about renaming the files since the mods may need their original names to function properly. And yes I am trying to move the entire installation with all the mods/tools/whatever, instead of leaving just the game to Program Files.

 

You can try moving the files in parts instead but if that is not working then you may want to go this route.

 

https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/robocopy

 

 (1) destination should include the folder name if copying the folder - e.g. if copying C:\Windows to D:\Windows the command would be robocopy /E C:\Windows D:\Windows (i.e. not robocopy /E C:\Windows D:\). (2) Can move files instead of copying them by using the /MOVE option

 

source, https://superuser.com/questions/216704/how-to-copy-files-that-have-too-long-of-a-filepath-in-windows

 

If you are really in a hurry use a linux boot drive or disc and boot the machine with linux and move delete whatever you need just be careful.

[Jindale]

I'm not that technically literate to know my way around anything linux.

 

So far I am mostly confused about the robocopy, and on top pf that I have NO registry edit for MAX_PATH nor LongPathsEnable whatsoever, and I do not kno how to create those. Windows wont even allow me to put the \\?\ designation on paths that is supposed to circumvent the long path name limitation.

 

And I'd still like to know is there anything inherently wrong with the load order or the resources in MO.

 

EDIT

Yeah okay I managed to move it all to another location, and I still get the big long error I mentioned in the OP. I am at loss. Pure hardware malfunction?

 

EDIT2

For some unkown reason of black magic for all I care, the memory error in its entirety has disappeared from MO.

 

This was after I made a subfolder for the FNIS tools, scripts and meshes in the Overwrite foler. MO still obviously warns me about files in the Overwrite, but as I said in the OP, this should not cause issues since I don't really use other profiles than the default. (Just something I've read around LL.) I also increased the scrapHeadSizeMB to 384 in SKSE.ini, which may have checked it off, but I do not know.

[RW311]

I am no expert on load orders because I am not up to date on mods in the least. If you ran loot but are not confident with the outcome then using tes5edit and just load all mods and look at what conflicts are remaining. 

[Jindale]

Sorry to bump my own thread, but this might be relevant to anyone having the same error.

 

The error in MO's log seems to be generated from the harmless crashes LOOT may have during its runtime, and this is naturally logged into windows as an application failure. The error got cleared out after successfully running and exiting LOOT within the MO. But so far these seem to be one-time errors generated by MO, and not the system.