Jump to content

Windows bug robs CPU in later builds


Lucifer1945

Recommended Posts

Service "system and compressed memory", source file "ntoskrnl" cannot be removed, ended, or disabled by method: Right click start bar, select computer management, Task scheduler (Scroll down and/or fullscreen/enlarge window), ProcessMemoryDiagnosticEvents, "RunFullMemoryDiagnostic". Disabling this and restarting in previous updates, possibly builds (Doesn't afflict super early builds) would turn off this service. It was introduced as an update some time ago, but in the last windows update this features control over operation mysteriously broke. If you have enough ram, and fast ram all it does it kill battery and drain potential from the CPU. Reported to Microsoft but if anyone has a solution to get rid of this or a concern, please share with the community.
 

 

Edited by Lucifer1945
Link to comment
Share on other sites


  • 2 weeks later...

Edit: This post is now obsolete, see new thread for optimization content. In however long it takes to upload to youtube, from the time of this posting. 

Edited by Lucifer1945
Link to comment
Share on other sites

On 6/17/2016 at 8:02 PM, Lucifer1945 said:

Minor tweak:

Download Large Address Aware. This program can force 32bit games to run in 64 bit. It has limited usefullness however good this sounds because it appears to not support full blown 64bit processing features as it doesnt make them automatically perform like going from 32bit crysis 1 to 64bit (I suspect that's because the dev isn't taking advantage of the potential), but it does allow the ram limit to be exceeded without the game crashing. It may be possible this can improve performance but again, probably not and its not like it uses any overhead. More a stability software. Set save and forget.

    Large Address Aware doesn't make 32-bit programs run 64-bit.  Another simple program that can do this tweak is NTCore's 4GB Patch.  Unless a 32-bit EXE has the LAA flag set, Windows will run it as 31-bit by default, limiting it to 2GiB of RAM.  This was fine in 32-bit Windows because you'd never want a single process to use that much RAM anyway.  But when 64-bit Windows came out, Microsoft raised that limit to include the full 32-bits.  The problem is, some older programs are compiled using signed Dwords to store memory pointers.  With a signed Dword, any address over 2GiB will appear negative, which can cause fatal errors in memory pointer offset calculations.

    Newer 32-bit programs that are compiled correctly can make full use of the 32-bits.  But just like with the new DPI-aware flag, many compilers fail to set the LAA flag, and the compiled binaries are thus limited to 31-bits by Windows.  That's where this tweak comes in, to modify the executable and set the LAA flag.  I have personally benefited from this tweak with VirtualDub, which isn't compiled as LAA, but works perfectly when tweaked.  It's a required tweak to use the Deshaker plugin on 1080p videos, as 2GiB RAM (31-bits) isn't enough.  After the tweak, the limit is raised to 4GiB (32-bits).    The flip side is that if you apply this tweak to an incompatible program, it will get more susceptible to crashing instead of less.

Link to comment
Share on other sites

I know it's a little OT, but how much of this is also applicable to Windows 7, or is there a current Windows 7 version of this guide?

Cheers and Regards

Edited by bphlpt
Link to comment
Share on other sites

  • 2 weeks later...

Removed user management. I didnt realize it was the culprit for a broken taskbar, im surprised no one said anything. I spent literally days making a user interface walkthrough that even with video editing is about an hour long. All I need is to add some task scheduler holes I missed, somehow I had the number in the mid to high 40's, and to put all the content (I have 98% of it done and edited) into one video, and then upload it to youtube. Took down old video. People seemed to hate it, and I thought it was purely the format. They just dont speak up. One setting on the above, runtimebroker.exe i think it is from the process lasso section will remove the ability of the start bar power options functionality, yet they still work with control alt delete. Those reading this, do not make that change, and further.... i have spent countless hours on this and at the time of posting this revision, uploading PROOF it works. It is non edited video from an external source to prove im not unplugging the battery, task manager, task scheduler, administrative tools services, power management cpu % settings, applied overclock settings including voltages, the nvidia control panel applied settings, and the third party software on screen applied settings as proof the variables are exactly the same. The full guide in its user interface format will be released by next week, and it would be an honor if mr. Noel gave it a look when he (You) gets around to it to see that its worthy of the extra polish I know he can add to it. 

Edited by Lucifer1945
Link to comment
Share on other sites

On 6/22/2016 at 1:15 PM, Techie007 said:

    Large Address Aware doesn't make 32-bit programs run 64-bit.  Another simple program that can do this tweak is NTCore's 4GB Patch.  Unless a 32-bit EXE has the LAA flag set, Windows will run it as 31-bit by default, limiting it to 2GiB of RAM.  This was fine in 32-bit Windows because you'd never want a single process to use that much RAM anyway.  But when 64-bit Windows came out, Microsoft raised that limit to include the full 32-bits.  The problem is, some older programs are compiled using signed Dwords to store memory pointers.  With a signed Dword, any address over 2GiB will appear negative, which can cause fatal errors in memory pointer offset calculations.

    Newer 32-bit programs that are compiled correctly can make full use of the 32-bits.  But just like with the new DPI-aware flag, many compilers fail to set the LAA flag, and the compiled binaries are thus limited to 31-bits by Windows.  That's where this tweak comes in, to modify the executable and set the LAA flag.  I have personally benefited from this tweak with VirtualDub, which isn't compiled as LAA, but works perfectly when tweaked.  It's a required tweak to use the Deshaker plugin on 1080p videos, as 2GiB RAM (31-bits) isn't enough.  After the tweak, the limit is raised to 4GiB (32-bits).    The flip side is that if you apply this tweak to an incompatible program, it will get more susceptible to crashing instead of less.

Im not following why it wouldnt take the program and allow it a 64bit memory address capability unless that 31bit isnt a typo, and its allowing 32bit, hence 4gbs. I appreciate the input. Its more for the mod community. 

Link to comment
Share on other sites

It was an assumption. 31bit sounds outlandish, granted I havent had the mental energy to devote to researching it, but ill rework my guides explanation as I need rest. 

Edited by Lucifer1945
Link to comment
Share on other sites

After pestering microsoft help desk given it was the second time after months of waiting.

"Here is a quick fix for your issue.
Changed the registry value instead of using Autoruns:
window + R then type regedit from that look for this 
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Ndu

Change the Start value to 4 (for disable)."

It didnt fix my issue, but it does seem to help reduce the activity of this stupid ram compression service. I also asked him to forward my thoughts on the idiotic nature of making the service impossible to decompile since the "bug" so it could be removed forcibly, and most of all, running it in SAFE MODE. A place people will be sure to be running their lightroom studio, crysis 3, video editing software, along with everything that tests the mettle of ram availability. 

Edited by Lucifer1945
Link to comment
Share on other sites

"system and compressed memory" is kernel process

mostly every application might effect it

its better check Resource Monitor to see which file/s is been written to

then u can have clue which process / service cause it

In windows 7 its was much easier to find the service that cause the problem

Windows 10 hides everything from the user, and doesnt help ITPro

Edited by aviv00
Link to comment
Share on other sites

It ranges from 0% usage to 1.3% (Probably higher when im not looking) on this CPU. Thats pretty significant compared to everything else ive written combined. Just now discovering a lot of the things listed the batch file recommended to me kills in script. Apparently task schedulers main menu isnt the be all end all, the drop down includes more. Pretty confident ive done everything that is possible short of "super hidden" stuff, like you said that is hidden from users. The only thing I can think of left, is wondering if its possible to take ntfs files and convert them into raw uncompressed versions even if it means bandwidth used would be higher, but I would think it would save CPU processing power if you strategically uncompressed key OS files. As far as I know this isnt possible. My desktops 3400mhz dual channel wouldnt sweat a little more abuse of its strengths over say my notebooks temporary 1600 dual, soon to be 2133. In DX11, the bottleneck is clearly CPU, even with a binned skylake including the memory controller. Overkill crossfire, high resolution, intense titles, the picture becomes clear, OS overhead plays a role. Come dx12 that isnt same lame port, my efforts will be mostly the work of obsessive compulsive just because I cans. 

I wish I knew someone sophisticated enough to decompile this kernal so it can be forcibly eradicated via deletion. I realize it would take them 5 to 30 minutes of their precious time to fix even if it was a crude work around stand alone tool, but they wont be bothered. I suspect its implementation in safe mode evidence not of laziness, but of conspiracy to elect a higher demand in the market stagnation for faster hardware, probably in more ways than we will be allowed know. The gimptatorship of software, hence the auto, surprise you are now a proud owner of windows 10 upon clicking the magic x marks the spot at prompt to leave your trusty former OS. Its blatantly pressure to get people out of the, its fast enough rut. ;) Tempted to try a forum where people discuss how to manipulate windows in less than legal ways, but then theres the prized jewel of no such agency who plays the same game, but the rules dont apply. 

Edited by Lucifer1945
Link to comment
Share on other sites

On 7/4/2016 at 7:37 AM, Lucifer1945 said:

Im not following why it wouldnt take the program and allow it a 64bit memory address capability unless that 31bit isnt a typo, and its allowing 32bit, hence 4gbs. I appreciate the input. Its more for the mod community. 

    Correct, 31 wasn't a typo.  As I explained in my previous post, the 32nd bit is the sign-bit (minus sign) when using a signed variable to store the memory pointer.  A signed Dword can express numbers from -2,147,483,648 to 2,147,483,647 (2 GiB), while an unsigned Dword can express numbers from 0 to 4,294,967,295 (4 GiB).  Memory pointers are supposed to be stored in unsigned variables, but older programs were not always written or compiled correctly because 32-bit Windows never even supported LAA (the use of the full 32-bits) per-process.  For instance, Visual Basic 6 doesn't even have support for an unsigned Dword.  Internally, the compiler and runtime calculate LAA memory pointers fine, but if I had to work with a memory pointer in code and offset it, it could get calculated incorrectly if LAA was manually enabled and I didn't use the 64-bit (Currency) variable in my code to handle the larger numbers expressed by the 32nd bit.

    This was never was an issue until 64-bit Windows came out on machines with over 4GiB of RAM and it was reasonable for Microsoft to enable use of the full 32-bit addressing range of 4 GiB of RAM on 32-bit processes.  That's where the LAA flag comes in, for a 32-bit program to signal its awareness and support of the 32nd bit under 64-bit Windows.  Under 32-bit Windows, using a signed Dword for memory pointers never caused any issue, because a memory address could never go beyond 2 GiB (31-bits).  But by manually enabling LAA on a 32-bit process under 64-bit Windows, we are breaking that expectation.  Which is fine if the program doesn't manipulate memory pointers or was coded correctly to use an unsigned Dword for memory pointers.

    The bigger point is that there is no performance to be gained by indiscriminately enabling LAA everywhere, and it will not make a 32-bit program to run as a 64-bit program.  It will still use the 32-bit Windows libraries, still be limited to an absolute maximum of 4 GiB of RAM no matter how much is installed on the PC.  Enabling LAA on programs that don't need it (programs that don't use very much RAM) won't accomplish anything, and enabling it on programs that were compiled/written incorrectly could increase the risk of a crash.  The only positive usage scenario for that tweak is in the case of a correctly written and compiled program that uses a lot of RAM, but was failed to be marked as Large Address Aware at compilation time.  Like VirtualDub and probably a good number of 32-bit games.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...