2019 Skyrim LE Stability Guide

[GenioMaestro]

7 hours ago, mrsrt said:

Now, you're continuing to show your incompetence and inability to understand things we're talking about. Okay, I'll try it to explain like to a child.

Please, stop talking about unnecesary things and posting unusefull link to the wiki. I have 50 years, i work as professional developer for 30 years, i develop in c++ for 20 years... I not need any of yours explanations. 

Spoiler

 

I make all the things that you make and propably more. I can download IDA in any moment but i perfectly know that not go to say me WHY the game make CTD. In the same way i used WinDbg for debug the windows kernel while i developing drivers for windows. I know very well WHEN the problem is caused by the source code or by the dll's or by the drivers. Please, stop writting unnecesary things.

 

7 hours ago, mrsrt said:

Have you ever create a platform-specific software?

And the problem show on only ONE machine? NOT, show in "very few users" showing the same problem.

And you think in a problem in the source code? NOT, because the code works in the 99.99% of the machines.

Where was the problem? A limitation in the machine or a problem in the drivers. None related to code.

 

7 hours ago, mrsrt said:

And yes, in 2020 CPUs still have different sets of that instructions and even different versions of sets:

And where is the problem? Maybe you think a game can stop working because we buy the most new and addvanced processor? NOT. Only can stop works when the machine not meet the minimun requeriments, as minimun version of OpenGL or minimun PixelShader, or have defective hardware or is bad configured. 

 

 

Any computer must execute, whitout any problem, any program whitout any exception. When the computer not make that only can be caused by failed minimun requeriments or problems in the configuration or defective hardware.

Please, i work with computers all my life. My first computer was an Amstrad 464 with cassete. I develop my first program in GWBasic with less than 10 years. I install Windows 3.0 with 5 diskettes of 1.44 mb. And of course, i install hundreds of windows 95, 98, XP, servers NT 3.51, NT 4.0 and hundreds of windows servers from 2000 to 2008 with SQL. 

I know very well WHEN a computer have a harware fail or a problem in configuration.

 

7 hours ago, mrsrt said:

I downloaded the preloader several times, but don't use it on the main game. I also may download a mod and never install it. These numbers say nothing, and you cannot know how many players use some mod/tweak right now. You cannot even know how many players play right now, because many users may have a non-steam copy of the game as me. 

Of course, not everybody that download a mod use it always in every play. But when we talk about the mod that solve 99% of the problems in the game i really doubth any player remove it.

Nobody can know exactly how many people are ussing OsAllocators and for that is said:

11 hours ago, GenioMaestro said:

How many of the 10k actual players have OsAllocators. I presume, at least, 2k but can be half or more.

You read the words "I presume"? Because i can not aseverate it. In the same way, i can not count the players with non-steam version and for that i only talk about numbers that every body can verify. I get it from SteamCharts. Look how the game have now 5k players and max is 12,631 in the past 24 hours.

 

 

Now, go to talk about the only important thing:

7 hours ago, mrsrt said:

It may occur on an absolutely random place, but some of them has much higher probably like whiterun stables and the default game start near Helgen. The best way to test it is to start the game without alternative start and while "Bethesda Game Studios" logo appears the game crashes. 

That have me think in a problem in horse skeleton. Are you totally sure you are ussing a PURE VANILLA game?

Have you deleted any folder inside DATA?

Maybe you have cleaned your installation and have some bad skeleton or bad mesh or bad animation.

Some users report problems with HD Resolution Pack. Disable it.

 

Another problem can come from framerate. Seems you have a very powerfull computer and the Havok Engine of the game can go crazy and cause CTD when have more than 60 fps. Limit your framerate in the control panel of your video card.

 

Verify you are ussing the correct d3dx9_42.dll because i see some users ussing a dll with that name that is not the correct dll from the pluging preloader. Be sure you not have any other dll that can cause problems.

Remove any background program, like antivirus and hardware monitors.

 

Reinstall Directx June 2010, Visual C++ Runtime 2010 in x32 and x64 and Visual C++ Runtime 2013 in x32 and x64.

 

Finaly, try with another user. Create a new user in the computer and try launch the game.

 

If the problems persist continue searching the cause because never, absolutelly never, can be caused by a diferent harware. Any game and any mods works in any computer in the world that match the minimun requeriments no matter if the computer is new or old. The problem never, absolutelly never, can be in the source code because all the games use the same source code.

[mrsrt]

16 minutes ago, GenioMaestro said:

Please, stop talking about unnecesary things and posting unusefull link to the wiki. I have 50 years, i work as professional developer for 30 years, i develop in c++ for 20 years... I not need any of yours explanations. 

Then I absolutely don't understand why do you writing here things which are totally false and which any cpp developer must know from the very beginning of his profession. And I said it again, hardware has influence on how memory pattern of process builds and what data will be written next to the array. Hardware does not cause the problem, however it can affect on protected memory area to appear next to the array. In other words, on some PC the problem may appear more often than on others.

However, you're absolutetly right with one thing, it's unnecessary information, the only real fact is the CTD which pop ups with os allocators.

 

33 minutes ago, GenioMaestro said:

And the problem show on only ONE machine? NOT, show in "very few users" showing the same problem.

I'm not sure if I understand your words correct here, and probably you didn't understand my message. I'll just explain my words.

When the software was given for tests most of users didn't have any problems and use it well, as probably most of users of os allocators. But the unlucky part of them with Intel HD Graphics had problems and these problems was related to their hardware, what possibly can be with os allocators too. As a developer you must met many bugs which appear only in rare specific cases and/or only on specific platform/hardware. This is not a problem of OS, PC, or even the game, the problem related to any platform-dependent development. I don't claim here that the crash strictly realted to platform, but you cannot claim opposite. Behaviour of software differs between PCs on basic level, and if the software has problems, i'll say it again, it may affect on frequency of problem appearing. This is what I meant.

 

59 minutes ago, GenioMaestro said:

And where is the problem? Maybe you think a game can stop working because we buy the most new and addvanced processor? NOT. Only can stop works when the machine not meet the minimun requeriments

Exactly. If your PC does not meet requirements for software the software will not work, or even worse. And it is not guaranteed to get all requirements with a new PC. For example AVX2 and AMD, check when it appeard on Intel and when on AMD. And this is again far away from topic.

 

1 hour ago, GenioMaestro said:

I know very well WHEN a computer have a harware fail or a problem in configuration.

Then why do you write how you install OS instead of facts that make you think it is not a platform dependent problem?

 

1 hour ago, GenioMaestro said:

That have me think in a problem in horse skeleton. Are you totally sure you are ussing a PURE VANILLA game?

Well, I removed all dll's, esp's, ini's, disabled enb, and used the default texture pack (not the "high-res" one provided with LE), so, I'd say it is vanilla enough for the test. Horses the first thing i was checked, this is not the case.

 

1 hour ago, GenioMaestro said:

Have you deleted any folder inside DATA?

Maybe you have cleaned your installation and have some bad skeleton or bad mesh or bad animation.

How is it possible to appear CTD caused by some mesh which doesn't appear without os allocators, especially when crashfix fixes itself most of possible problems with meshes?

 

1 hour ago, GenioMaestro said:

Another problem can come from framerate. Seems you have a very powerfull computer and the Havok Engine of the game can go crazy and cause CTD when have more than 60 fps. Limit your framerate in the control panel of your video card.

The only thing make it crazy is desync, which fixed with HavocFix. Btw, already tested too.

 

1 hour ago, GenioMaestro said:

Verify you are ussing the correct d3dx9_42.dll because i see some users ussing a dll with that name that is not the correct dll from the pluging preloader. Be sure you not have any other dll that can cause problems.

It's valid. Crashfix would give message if I hadn't valid preloader.

 

1 hour ago, GenioMaestro said:

Remove any background program, like antivirus and hardware monitors.

Don't use such things.

 

1 hour ago, GenioMaestro said:

Reinstall Directx June 2010, Visual C++ Runtime 2010 in x32 and x64 and Visual C++ Runtime 2013 in x32 and x64.

Installed every possible pack from MSDN.

 

1 hour ago, GenioMaestro said:

Finaly, try with another user. Create a new user in the computer and try launch the game.

This is what I woundn't do, because see no relation to the problem. My OS was installed a few months ago, and on previous one I had problems with os allocators too, but different. It was texture disappearing and flickering. 

 

1 hour ago, GenioMaestro said:

The problem never, absolutelly never, can be in the source code because all the games use the same source code.

What??? Then what do you think bethesda updated with their patches for the game? What do you think does crashfix plugin besides allocation? And how the source code between games can be the same??? Maybe I didn't get your point.

 

Btw, I'll continue searching the real problem.

[GenioMaestro]

7 hours ago, mrsrt said:

Then I absolutely don't understand why do you writing here things which are totally false and which any cpp developer must know from the very beginning of his profession. And I said it again, hardware has influence on how memory pattern of process builds and what data will be written next to the array. Hardware does not cause the problem, however it can affect on protected memory area to appear next to the array. In other words, on some PC the problem may appear more often than on others.

I not know where you learn to develop but you must understand that yours owns words not have any sense.

I going to put this in a spoiler because is the last time i teach you:

Spoiler

The only true part is "Hardware does not cause the problem" but the words "hardware has influence..." not have any relation because the hardware NEVER can have any DIRECT influence in the memory management of the computer. The only influence can be caused by the DRIVERS that connect whit the hardware and, of course, diferent hardware have diferent drivers. But the driver is a program that isolate the hardware from the software. If we have a problem only can be caused by defective hardware or bad drivers.

 

Each diferent driver reserve their own memory zones for transfer buffers and store their own data:

 

What have the memory near our addres is totally indiferent. No matter if the zone is owned by a driver or by other program because any program that try read a memory address outside their assigned address get the error "Invalid addres" from the operating system. 

Only the operating system have the memory map and only the operating system know the owner of each address. The error "Invalid addres" is not generated by the CPU. Is generated by the operating system.

 

If we have an array with 7 elemts, from 0 to 6, when we try access the element 7 the operating system generate the error "Invalid addres" because that address is outside our own zone. No matter what have that address because 99.99% of the times that address is empty. The content of that zone can depend of our drivers that depend of our hardware. But that not matter. The error is not caused because that address is asigned to other process. The error happend because we not own that adders.

 

If you are thinking that the error NOT happend when that address is not ussed and ONLY happend when the addres is filled you are totally wrong.  If you are thinking that the error CAN depend of the content of that address you are totally wrong because we can not access the content of that address.

 

Talking abut your specific problem:

7 hours ago, mrsrt said:

Well, I removed all dll's, esp's, ini's, disabled enb, and used the default texture pack (not the "high-res" one provided with LE), so, I'd say it is vanilla enough for the test. Horses the first thing i was checked, this is not the case.

 

The only thing make it crazy is desync, which fixed with HavocFix. Btw, already tested too.

 

It's valid. Crashfix would give message if I hadn't valid preloader.

 

Don't use such things.

 

Installed every possible pack from MSDN.

 

This is what I woundn't do, because see no relation to the problem.

 

Btw, I'll continue searching the real problem.

Try creating a new user. A lot of times i have problems in 95, 98 and XP caused by corrupted user. I not have the problem in Win7 but have it in Win8. Not know if Win10 have the problem of corrupted user.

 

You can make some test with the version V2 of the preloader and try the version 10 and 11 from Crash Fixes but i presume you go to have the same results. 

 

If you really want locate the problem make a test in a Win7 machine.

If you not have a Win7 machine make a parallel installation in a partion of your hard disk.

If the vanilla game NOT works with OsAlocators in Win7 can be a hardware or driver problem.

If the vanilla game WORKS with OsAlocators in Win7 delete the parallel Win7 and install a parallel Win10.

If the vanilla game NOT works with OsAlocators in Win10 in a diferent installation can be a problem related exclusively to Win10 and OsAlocators but i not see any report about it.

[mrsrt]

Spoiler

12 hours ago, GenioMaestro said:

I not know where you learn to develop but you must understand that yours owns words not have any sense.

...

The only true part is "Hardware does not cause the problem" but the words "hardware has influence..." not have any relation because the hardware NEVER can have any DIRECT influence in the memory management of the computer.

I really surprised that you're talking such things. 

 

12 hours ago, GenioMaestro said:

Each diferent driver reserve their own memory zones for transfer buffers and store their own data

Why do you mention static driver reservations when we're talking about dynamic memory allocations inside process? This is indeed something what absolutely has no relation nor for the topic nor for the spoiler.

 

12 hours ago, GenioMaestro said:

What have the memory near our addres is totally indiferent. No matter if the zone is owned by a driver or by other program because any program that try read a memory address outside their assigned address get the error "Invalid addres" from the operating system.

Wrong, you can always write to and read from another process through kernel32.dll. The only thing that matters if memory is protected. Btw, this is again far away from everything we're talking here, the CTD caused by reading process memory area that is protected, and not outside of process. 

 

12 hours ago, GenioMaestro said:

If you are thinking that the error CAN depend of the content of that address you are totally wrong because we can not access the content of that address.

Now I really have doubts that you're a real C++ developer. And now I'll show you with a real example how wrong you are:

Spoiler

int main()
{
	const int allocs = 9;
	const int block_size = 64;
	int* ptrs[allocs]; // holding pointers of blocks
	for(int i = 0; i < allocs; i++)
	{
		int* ptr = (int*)malloc(block_size * sizeof(int)); // allocate several blocks in a row and store their pointers
		ptrs[i] = ptr;
		for(int j = 0; j < block_size; j++)
		{
			ptr[j] = 111 * i; // fill blocks with mask by index: 3 -> 333, 4 -> 444
		}
	}

	int* ptr = ptrs[7]; // get pointer for one of inner allocated block
	for(int i = 0; i < 100; i++) // print values of the block and 36 more next memory cells after it
	{
		cout << "idx: " << i << ", value: " << ptr[i] << endl;
	}
}

 

 

Output:

Spoiler

idx: 0, value: 777
idx: 1, value: 777
idx: 2, value: 777
idx: 3, value: 777
idx: 4, value: 777
idx: 5, value: 777
idx: 6, value: 777
idx: 7, value: 777
idx: 8, value: 777
idx: 9, value: 777
idx: 10, value: 777
idx: 11, value: 777
idx: 12, value: 777
idx: 13, value: 777
idx: 14, value: 777
idx: 15, value: 777
idx: 16, value: 777
idx: 17, value: 777
idx: 18, value: 777
idx: 19, value: 777
idx: 20, value: 777
idx: 21, value: 777
idx: 22, value: 777
idx: 23, value: 777
idx: 24, value: 777
idx: 25, value: 777
idx: 26, value: 777
idx: 27, value: 777
idx: 28, value: 777
idx: 29, value: 777
idx: 30, value: 777
idx: 31, value: 777
idx: 32, value: 777
idx: 33, value: 777
idx: 34, value: 777
idx: 35, value: 777
idx: 36, value: 777
idx: 37, value: 777
idx: 38, value: 777
idx: 39, value: 777
idx: 40, value: 777
idx: 41, value: 777
idx: 42, value: 777
idx: 43, value: 777
idx: 44, value: 777
idx: 45, value: 777
idx: 46, value: 777
idx: 47, value: 777
idx: 48, value: 777
idx: 49, value: 777
idx: 50, value: 777
idx: 51, value: 777
idx: 52, value: 777
idx: 53, value: 777
idx: 54, value: 777
idx: 55, value: 777
idx: 56, value: 777
idx: 57, value: 777
idx: 58, value: 777
idx: 59, value: 777
idx: 60, value: 777
idx: 61, value: 777
idx: 62, value: 777
idx: 63, value: 777
idx: 64, value: -33686019
idx: 65, value: 0
idx: 66, value: -1626084543
idx: 67, value: 201374758
idx: 68, value: 13108728
idx: 69, value: 13109336
idx: 70, value: 0
idx: 71, value: 0
idx: 72, value: 1
idx: 73, value: 256
idx: 74, value: 168
idx: 75, value: -33686019
idx: 76, value: 888
idx: 77, value: 888
idx: 78, value: 888
idx: 79, value: 888
idx: 80, value: 888
idx: 81, value: 888
idx: 82, value: 888
idx: 83, value: 888
idx: 84, value: 888
idx: 85, value: 888
idx: 86, value: 888
idx: 87, value: 888
idx: 88, value: 888
idx: 89, value: 888
idx: 90, value: 888
idx: 91, value: 888
idx: 92, value: 888
idx: 93, value: 888
idx: 94, value: 888
idx: 95, value: 888
idx: 96, value: 888
idx: 97, value: 888
idx: 98, value: 888
idx: 99, value: 888

As you can see we can access to memory address area of the next block/array. Actually, this result is unpredicted, OS can store the block with mask 777 or 888 in a different place. However, if algorithm of allocations doesn't change and allocators don't meet fragmented area there's a very high probability that these blocks will be allocated one by one in a row.

Now let's emulate some loading and split allocations between threads. I also reduced allocation/thread amount to 3 to make difference more noticable:

Spoiler

const int allocs = 3;
const int block_size = 64;
int* ptrs[allocs]; // holding pointers of blocks

void b_alloc(int b_idx)
{
	int* ptr = (int*)malloc(block_size * sizeof(int)); // allocate several blocks in a row and store their pointers
	ptrs[b_idx] = ptr;
	for (int j = 0; j < block_size; j++)
	{
		ptr[j] = 111 * b_idx; // fill blocks with mask by index: 3 -> 333, 4 -> 444
	}
}

int main()
{
	thread threads[allocs];
	for(int i = 0; i < allocs; i++)
	{
		threads[i] = thread(b_alloc, i); // starting several threads with block allocations and store them in the thread array.
										 // index will be given to each thread and used as identifier
	}
	for(int i = 0; i < allocs; i++)
	{
		threads[i].join(); // wait for each thread to be finished
	}
	int* ptr = ptrs[1]; // get pointer for one of inner allocated block
	for(int i = 0; i < 100; i++) // print 64 values of the block and 36 more next memory cells after
	{
		cout << "idx: " << i << ", value: " << ptr[i] << endl;
	}
}

 

 

Now results is completely random due to race condition.

We can see block 0 next to block 1:

Spoiler

idx: 0, value: 111
idx: 1, value: 111
idx: 2, value: 111
idx: 3, value: 111
idx: 4, value: 111
idx: 5, value: 111
idx: 6, value: 111
idx: 7, value: 111
idx: 8, value: 111
idx: 9, value: 111
idx: 10, value: 111
idx: 11, value: 111
idx: 12, value: 111
idx: 13, value: 111
idx: 14, value: 111
idx: 15, value: 111
idx: 16, value: 111
idx: 17, value: 111
idx: 18, value: 111
idx: 19, value: 111
idx: 20, value: 111
idx: 21, value: 111
idx: 22, value: 111
idx: 23, value: 111
idx: 24, value: 111
idx: 25, value: 111
idx: 26, value: 111
idx: 27, value: 111
idx: 28, value: 111
idx: 29, value: 111
idx: 30, value: 111
idx: 31, value: 111
idx: 32, value: 111
idx: 33, value: 111
idx: 34, value: 111
idx: 35, value: 111
idx: 36, value: 111
idx: 37, value: 111
idx: 38, value: 111
idx: 39, value: 111
idx: 40, value: 111
idx: 41, value: 111
idx: 42, value: 111
idx: 43, value: 111
idx: 44, value: 111
idx: 45, value: 111
idx: 46, value: 111
idx: 47, value: 111
idx: 48, value: 111
idx: 49, value: 111
idx: 50, value: 111
idx: 51, value: 111
idx: 52, value: 111
idx: 53, value: 111
idx: 54, value: 111
idx: 55, value: 111
idx: 56, value: 111
idx: 57, value: 111
idx: 58, value: 111
idx: 59, value: 111
idx: 60, value: 111
idx: 61, value: 111
idx: 62, value: 111
idx: 63, value: 111
idx: 64, value: -33686019
idx: 65, value: 0
idx: 66, value: -1802376518
idx: 67, value: 201375825
idx: 68, value: 16926088
idx: 69, value: 16928480
idx: 70, value: 0
idx: 71, value: 0
idx: 72, value: 1
idx: 73, value: 256
idx: 74, value: 171
idx: 75, value: -33686019
idx: 76, value: 0
idx: 77, value: 0
idx: 78, value: 0
idx: 79, value: 0
idx: 80, value: 0
idx: 81, value: 0
idx: 82, value: 0
idx: 83, value: 0
idx: 84, value: 0
idx: 85, value: 0
idx: 86, value: 0
idx: 87, value: 0
idx: 88, value: 0
idx: 89, value: 0
idx: 90, value: 0
idx: 91, value: 0
idx: 92, value: 0
idx: 93, value: 0
idx: 94, value: 0
idx: 95, value: 0
idx: 96, value: 0
idx: 97, value: 0
idx: 98, value: 0
idx: 99, value: 0

 

Or block 2 next to block 1:

Spoiler

idx: 0, value: 111
idx: 1, value: 111
idx: 2, value: 111
idx: 3, value: 111
idx: 4, value: 111
idx: 5, value: 111
idx: 6, value: 111
idx: 7, value: 111
idx: 8, value: 111
idx: 9, value: 111
idx: 10, value: 111
idx: 11, value: 111
idx: 12, value: 111
idx: 13, value: 111
idx: 14, value: 111
idx: 15, value: 111
idx: 16, value: 111
idx: 17, value: 111
idx: 18, value: 111
idx: 19, value: 111
idx: 20, value: 111
idx: 21, value: 111
idx: 22, value: 111
idx: 23, value: 111
idx: 24, value: 111
idx: 25, value: 111
idx: 26, value: 111
idx: 27, value: 111
idx: 28, value: 111
idx: 29, value: 111
idx: 30, value: 111
idx: 31, value: 111
idx: 32, value: 111
idx: 33, value: 111
idx: 34, value: 111
idx: 35, value: 111
idx: 36, value: 111
idx: 37, value: 111
idx: 38, value: 111
idx: 39, value: 111
idx: 40, value: 111
idx: 41, value: 111
idx: 42, value: 111
idx: 43, value: 111
idx: 44, value: 111
idx: 45, value: 111
idx: 46, value: 111
idx: 47, value: 111
idx: 48, value: 111
idx: 49, value: 111
idx: 50, value: 111
idx: 51, value: 111
idx: 52, value: 111
idx: 53, value: 111
idx: 54, value: 111
idx: 55, value: 111
idx: 56, value: 111
idx: 57, value: 111
idx: 58, value: 111
idx: 59, value: 111
idx: 60, value: 111
idx: 61, value: 111
idx: 62, value: 111
idx: 63, value: 111
idx: 64, value: -33686019
idx: 65, value: 0
idx: 66, value: -277708653
idx: 67, value: 201353364
idx: 68, value: 16600504
idx: 69, value: 16601112
idx: 70, value: 0
idx: 71, value: 0
idx: 72, value: 1
idx: 73, value: 256
idx: 74, value: 176
idx: 75, value: -33686019
idx: 76, value: 222
idx: 77, value: 222
idx: 78, value: 222
idx: 79, value: 222
idx: 80, value: 222
idx: 81, value: 222
idx: 82, value: 222
idx: 83, value: 222
idx: 84, value: 222
idx: 85, value: 222
idx: 86, value: 222
idx: 87, value: 222
idx: 88, value: 222
idx: 89, value: 222
idx: 90, value: 222
idx: 91, value: 222
idx: 92, value: 222
idx: 93, value: 222
idx: 94, value: 222
idx: 95, value: 222
idx: 96, value: 222
idx: 97, value: 222
idx: 98, value: 222
idx: 99, value: 222

 

Or absolutely random data when block 1 was allocated last:

Spoiler

idx: 0, value: 111
idx: 1, value: 111
idx: 2, value: 111
idx: 3, value: 111
idx: 4, value: 111
idx: 5, value: 111
idx: 6, value: 111
idx: 7, value: 111
idx: 8, value: 111
idx: 9, value: 111
idx: 10, value: 111
idx: 11, value: 111
idx: 12, value: 111
idx: 13, value: 111
idx: 14, value: 111
idx: 15, value: 111
idx: 16, value: 111
idx: 17, value: 111
idx: 18, value: 111
idx: 19, value: 111
idx: 20, value: 111
idx: 21, value: 111
idx: 22, value: 111
idx: 23, value: 111
idx: 24, value: 111
idx: 25, value: 111
idx: 26, value: 111
idx: 27, value: 111
idx: 28, value: 111
idx: 29, value: 111
idx: 30, value: 111
idx: 31, value: 111
idx: 32, value: 111
idx: 33, value: 111
idx: 34, value: 111
idx: 35, value: 111
idx: 36, value: 111
idx: 37, value: 111
idx: 38, value: 111
idx: 39, value: 111
idx: 40, value: 111
idx: 41, value: 111
idx: 42, value: 111
idx: 43, value: 111
idx: 44, value: 111
idx: 45, value: 111
idx: 46, value: 111
idx: 47, value: 111
idx: 48, value: 111
idx: 49, value: 111
idx: 50, value: 111
idx: 51, value: 111
idx: 52, value: 111
idx: 53, value: 111
idx: 54, value: 111
idx: 55, value: 111
idx: 56, value: 111
idx: 57, value: 111
idx: 58, value: 111
idx: 59, value: 111
idx: 60, value: 111
idx: 61, value: 111
idx: 62, value: 111
idx: 63, value: 111
idx: 64, value: -33686019
idx: 65, value: 0
idx: 66, value: -44566029
idx: 67, value: 2972
idx: 68, value: 11141072
idx: 69, value: 11147456
idx: 70, value: -572662307
idx: 71, value: -572662307
idx: 72, value: -572662307
idx: 73, value: -572662307
idx: 74, value: -572662307
idx: 75, value: -572662307
idx: 76, value: -572662307
idx: 77, value: -572662307
idx: 78, value: -572662307
idx: 79, value: -572662307
idx: 80, value: -572662307
idx: 81, value: -572662307
idx: 82, value: -572662307
idx: 83, value: -572662307
idx: 84, value: -572662307
idx: 85, value: -572662307
idx: 86, value: -572662307
idx: 87, value: -572662307
idx: 88, value: -572662307
idx: 89, value: -572662307
idx: 90, value: -572662307
idx: 91, value: -572662307
idx: 92, value: -572662307
idx: 93, value: -572662307
idx: 94, value: -572662307
idx: 95, value: -572662307
idx: 96, value: -572662307
idx: 97, value: -572662307
idx: 98, value: -572662307
idx: 99, value: -572662307

 

And now let's emulate for example disk access. Imagine each next data for each next block more and more fragmented, so access will be slower with each next alloc. If you don't trust that disk fragmentation may affect on read speed just check this: https://www.condusiv.com/disk-defrag/fragmentation-impact/

And the emulation code:

Spoiler

const int allocs = 3;
const int block_size = 64;
int* ptrs[allocs]; // holding pointers of blocks

void b_alloc(int b_idx)
{
	this_thread::sleep_for(chrono::milliseconds(100 * b_idx)); // emulating disk access with simple sleep like the time is taken for read
	string s;
	s.append("Block ").append(to_string(b_idx)).append(" allocated.\n");
	cout << s; // logging block allocation order
	int* ptr = (int*)malloc(block_size * sizeof(int)); // allocate several blocks in a row and store their pointers
	ptrs[b_idx] = ptr;
	for (int j = 0; j < block_size; j++)
	{
		ptr[j] = 111 * b_idx; // fill blocks with mask by index: 3 -> 333, 4 -> 444
	}
}

int main()
{
	thread threads[allocs];
	for(int i = 0; i < allocs; i++)
	{
		threads[i] = thread(b_alloc, i); // starting several threads with block allocations and store them in the thread array.
										 // index will be given to each thread and used as identifier
	}
	for(int i = 0; i < allocs; i++)
	{
		threads[i].join(); // wait for each thread to be finished
	}
	int* ptr = ptrs[1]; // get pointer for one of inner allocated block
	for(int i = 0; i < 100; i++) // print 64 values of the block and 36 more next memory cells after
	{
		cout << "idx: " << i << ", value: " << ptr[i] << endl;
	}
}

 

 

Now with 20 of 20 executes I get the same output where the next data to array always the same due to emulation of disk access:

Spoiler

Block 0 allocated.
Block 1 allocated.
Block 2 allocated.
idx: 0, value: 111
idx: 1, value: 111
idx: 2, value: 111
idx: 3, value: 111
idx: 4, value: 111
idx: 5, value: 111
idx: 6, value: 111
idx: 7, value: 111
idx: 8, value: 111
idx: 9, value: 111
idx: 10, value: 111
idx: 11, value: 111
idx: 12, value: 111
idx: 13, value: 111
idx: 14, value: 111
idx: 15, value: 111
idx: 16, value: 111
idx: 17, value: 111
idx: 18, value: 111
idx: 19, value: 111
idx: 20, value: 111
idx: 21, value: 111
idx: 22, value: 111
idx: 23, value: 111
idx: 24, value: 111
idx: 25, value: 111
idx: 26, value: 111
idx: 27, value: 111
idx: 28, value: 111
idx: 29, value: 111
idx: 30, value: 111
idx: 31, value: 111
idx: 32, value: 111
idx: 33, value: 111
idx: 34, value: 111
idx: 35, value: 111
idx: 36, value: 111
idx: 37, value: 111
idx: 38, value: 111
idx: 39, value: 111
idx: 40, value: 111
idx: 41, value: 111
idx: 42, value: 111
idx: 43, value: 111
idx: 44, value: 111
idx: 45, value: 111
idx: 46, value: 111
idx: 47, value: 111
idx: 48, value: 111
idx: 49, value: 111
idx: 50, value: 111
idx: 51, value: 111
idx: 52, value: 111
idx: 53, value: 111
idx: 54, value: 111
idx: 55, value: 111
idx: 56, value: 111
idx: 57, value: 111
idx: 58, value: 111
idx: 59, value: 111
idx: 60, value: 111
idx: 61, value: 111
idx: 62, value: 111
idx: 63, value: 111
idx: 64, value: -33686019
idx: 65, value: -572662307
idx: 66, value: 433268730
idx: 67, value: 201381326
idx: 68, value: 15925200
idx: 69, value: 15921976
idx: 70, value: 0
idx: 71, value: 0
idx: 72, value: 1
idx: 73, value: 256
idx: 74, value: 184
idx: 75, value: -33686019
idx: 76, value: 222
idx: 77, value: 222
idx: 78, value: 222
idx: 79, value: 222
idx: 80, value: 222
idx: 81, value: 222
idx: 82, value: 222
idx: 83, value: 222
idx: 84, value: 222
idx: 85, value: 222
idx: 86, value: 222
idx: 87, value: 222
idx: 88, value: 222
idx: 89, value: 222
idx: 90, value: 222
idx: 91, value: 222
idx: 92, value: 222
idx: 93, value: 222
idx: 94, value: 222
idx: 95, value: 222
idx: 96, value: 222
idx: 97, value: 222
idx: 98, value: 222
idx: 99, value: 222

 

Do you really still think we cannot access to memory cells outside of array area? Do you really still think hardware has no affection on process memory map? Do you really still think hardware cannot affect on what data will be stored next to the problematic array in the game? And I'll never belive that a real cpp developer with 20 years of exeprience doesn't know such basic things. 

 

12 hours ago, GenioMaestro said:

Try creating a new user. A lot of times i have problems in 95, 98 and XP caused by corrupted user. I not have the problem in Win7 but have it in Win8. Not know if Win10 have the problem of corrupted user.

...

If you really want locate the problem make a test in a Win7 machine.

If you not have a Win7 machine make a parallel installation in a partion of your hard disk.

If the vanilla game NOT works with OsAlocators in Win7 can be a hardware or driver problem.

If the vanilla game WORKS with OsAlocators in Win7 delete the parallel Win7 and install a parallel Win10.

If the vanilla game NOT works with OsAlocators in Win10 in a diferent installation can be a problem related exclusively to Win10 and OsAlocators but i not see any report about it.

Well, maybe later. I'm not ready to make a polygon of tests on my PC now. However, I still see no relation between active user and the problem, because as I said, the OS is very fresh and I'm not a user who ruin OS with shitty software and bad actions.

 

12 hours ago, GenioMaestro said:

You can make some test with the version V2 of the preloader and try the version 10 and 11 from Crash Fixes but i presume you go to have the same results. 

Business logic doesn't change between versions, final result will not change too.

[mrsrt]

This guide is outdated. New version was moved to blog and can be found here: https://www.loverslab.com/blogs/blog/1311-2020-skyrim-le-stability-guide/