Search the Community
Showing results for tags 'optimize'.
Found 2 results
-
So I have gone through group policy and shutdown everything I understand. completely disabled auto updates via group policy, and disabled all telemetry that can be disabled, consumer experiences, and everything else that can be shut down there. No apps, no cortana. Disabled unneeded services. Disabled all unneeded scheduled tasks. Now I am trying to minimize logging. Going through perfmon I find that there are a few logs which I can disable safely without any ill effects. The one that got me was WdiContextLog, as it took some trial and error to figure out that this was the one that caused the start menu to become extremely unresponsive when disabled. There aren't that many logs in here anyway. After disabling a few I have 11 enabled here. Now I don't completely understand how all this works, but I gather that these logs are pulling data from multiple sources in some cases, so maybe that is why NirSoft's EventLogChannelsView shows 299 event log channels as enabled. I am actually doing this for a friend just now, but it will apply to my own system when I get home next week as well. My friend initially wanted to just turn off all the logs, and he tried to, and he broke his OS - lots of strange behavior, extremely slow, and unstable. I'm not sure what all he did, but he was smart enough to take a disk image before his attempt. So I wonder if any of you smart people would not mind helping me to identify which of these 299 channels are essential, which are maybe not essential but might be important, and which are not really needed for someone like me (or my friend) who will never make use of any of them anyway. I really only want those ones running which have to be running for general application compatibility and system stability. EventLogChannelsView gives lots of options for sorting these. You can see which ones are 'classic' and which ones are new. I can see that many have zero entries, and a few have lots of entries. I temporarily disabled all of them, and shut down a number of services in order to open a window of opportunity to create a junction and move winevt directory off the system volume and onto a smaller cheap SSD which is used for vram, scratch disk, indexing, and logging. There was one (Intel-SST-CFD-HDA%4IntelSST.etl) that was very stubborn, but somehow I did manage to gain control of it long enough to create the junction. Then I re-enabled everything just as it was before that operation. Hope some of you might be willing to offer some deeper insight here. For list of enabled event channels see the spoiler at the bottom. As an aside, I am also very curious about NtfsLog in Perfmon. In Windows 10 I seem to recall it writing directly to D:0\$LogFile which is an integral part of the ntfs drive format. This file is presented as if it is essential for the volume to be able to recover failed writes due to unexpected shutdowns or some such. It seems like this is actually of limited use to average users. In general if our system shuts down suddenly, in the middle of writing data, we lose the data. Ntfs or no. Other file systems seem to work perfectly fine without this 'feature,' discounting potential data loss if shutdown mid-write. It seems to me like the major benefits of Ntfs are mostly not facilitated by this logfile. Such as bigger file sizes, and advanced permissions. I digress though. Shouldn't $LogFile be handled by the Ntfs driver or something on a very low level, rather than an event log? Maybe my recollection is mistaken. I will have to recheck Windows 10, but I could swear that the event log "NtfsLog" in perfmon startup was writing to D:0\$LogFile in win 10. Yet right now, I am looking at the very same entry on Server 2016 but it is writing to C:\Windows\system32\LogFiles\Wmi\NtfsLog, which kind of makes more sense. So what is up with NtfsLog?
-
Nuhi suggested that any further discussion of the new tool should take place here on the vLite forums, for now, so here goes. I have a suggestion for the name of the new tool. nLite was such a success, I think the new tool should retain the nLite name in some form. My suggestion is nLiteX, pronounced En Light Ex. It keeps the familiarity with nLite, avoids the problem of adding 7, 8, or numbers beyond that to the name. It also implies a new, expanded nLite with new capabilities, and ensures that the tool won't need to be renamed for future versions of Windows.
