Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


  • Content Count

  • Donations

  • Joined

  • Last visited

Community Reputation

7 Neutral

About multiversion

Profile Information

  • OS
    Windows 7 x64
  • Country
  1. That was just an aside, which I was curious about. But my question was not necessarily about $LogFile, on the root of any given ntfs drive. Rather I was asking about the the NtfsLog trace session which can be found in perfmon > data collector sets > startup event trace sessions. I had recalled in Win 10 that trace session was writing to the $LogFile on the system drive. I checked it though, and indeed I was mistaken in my recollection. It is writing to C:\Windows\system32\LogFiles\Wmi\NtfsLog on both Win 10 and Server 2016. Strange because I had a distinct memory that it was writing to $LogFile in Win 10, which seemed very strange, so I actually spent some time searching for info about it online. I guess maybe I dreamed that or something, memories from an alternate reality... Anyway, I was more interested in which of the channels shown as enabled in NirSoft's EventLogChannelsView might be safely disabled.
  2. So maybe you guys can give me some input even if you don't have specific answers for me. Am I asking too much here? Am I crazy to try to tone down the logging? Is it just not worth the effort? Is NirSoft's EventLogChannelsView entirely the wrong tool to tackle this? Am I not being clear enough? Am I just coming off as being too dense and clueless in general, and thus not worth your time? I will make use of and learn from any and all input offered, so even if you can't (for whatever reason), or maybe just don't feel like, answering my specific questions here, I would still appreciate your general thoughts, or any tips you might have.
  3. Another big problem with the direction MS is taking here, is that the behavior of the OS is all but indistinguishable from various forms of malware, to all but the most expert. Svchost is talking to this IP and that IP without any user input or user understanding. When I look up those IP addresses I often find three things. One they belong to MS or Akamai, and two, they have been reported by numerous people for abuse, malware, hacking, or some such. The third thing is that they are whitelisted as trusted by various authorities. So on the one hand, Windows 10 is supposed to be the most secure windows yet. On the other hand, people are reporting its behavior and contact addresses as malware, because I think many of those people honestly can't tell the difference. They just see unexplained connections that they didn't initiate and don't seem tied to any legit programs they have installed and think they are hacked or infected. Some report the IPs. Those who ask for help are told that it is the OS, and it is supposed to do that. So now they are probably going to just allow svchost to connect to whatever random IPs it wants to, whenever it wants to, with zero understanding of why (because the OS is just supposed to do that). That just doesn't sound like the most secure OS at all... Not to mention all the plethora of little things that are broken, and the updates which fail to fix those things but do manage to break more little things, and if you know anything about computer security, you know that the amount of bugs present in a piece of software, is generally a decent benchmark of the number of potentially exploitable security holes. Personally, I think we should be petitioning those authorities who have whitelisted MS' and Akamai's IP ranges as trusted to remove them from those whitelists. They are using our hardware and our bandwidth for their own purposes with practically zero transparency or consent. Yeah, I know the license agreement is a form of consent but in many ways it really isn't, because we can't consent to things which are not fully explained or disclosed, we are not told what is being sent by which processes to which IPs, and I believe that legally speaking consent without understanding is not generally binding. The lack of transparency here in fact introduces increased risks, which may well lead to actual damages, due to it being virtually impossible for average users to differentiate between the behavior of windows and malware. They are conducting themselves like trojans, and botnets, and subjecting people to needless risk, and should accordingly be removed from whitelists.
  4. 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?
  5. So Windows 10 really is a nightmare. It has wasted way too much of my time since installing it. Windows as a service, turns out to be Windows as 'your' servitude. The license agreement basically states that your hardware will be controlled by microsoft as long as you run their software. So if they are using my hardware as their surveillance system, and I have to maintain it for them when they keep forcing updates that break stuff, then shouldn't they be paying me? Personally, I think they are in some very gray territory legally. Really, I think they are way beyond grey. What they are doing is illegal in a dozen different ways at least. But the courts seem to be behind them, as the courts have been siding with corporations who have precluded class action lawsuits through their licensing agreements. The courts allowing licensing agreements to rule out class action lawsuits is basically a license for the corporations to get away with just about anything, no matter how shady. Because individual lawsuits will generally lack the financial and legal fortitude to go up against giants, and in those rare cases that they do, the cost of a settlement for the giants will be negligible and will not serve to curb their practices in any significant manner. Another thing that really makes me wonder too, is how shady are the enterprise licensing agreements. I have not gone through them in great detail. I mean currently in enterprise, it is possible to disable telemetry (which actually only sets it to a minimal level, so the setting of 0 is a bit misleading). It is also possible to redirect all telemetry data internally - though again, that does not really account for all telemetry, only some forms of telemetry. To really shut down all telemetry and gain complete control of updates is entirely possible, but it is also a lengthy and convoluted process which is liable to break some things, and seems intentionally designed to make it possible for admins who are not extremely thorough to miss something. The question though, is do the enterprise license agreements guarantee these 'features' of being able to control the software's penchant for phoning home? Just because the software allows these customizations at present, is there any guarantee that it will do so after the next update? Seems like some enterprises may be lulled into a false sense of security, by Microsoft including the ability to manage and control services, task schedules, logging, and set group policies according to their needs, rather than Microsoft's agenda. But is there any legally binding promise from Microsoft that such functionality will be supported in the future? Seems like a massive trap to me, and smart enterprises would probably do better to seriously look into other OSes at this point. I wish some of the big players would pour some resources into bringing ReactOS to maturity. That could be brilliant. It also seems to me that other companies who are supporting Microsoft's push for world domination, like Adobe, nVidia, Intel, Wacom, Lenovo, Dell, Etc.. Should really think twice at this point, because the moment MS doesn't need them anymore...
  6. I am in China just now, and due to current circumstances, online payments are not really practical for me at this time. That will change very soon though, at which point I will be happy to make a donation.
  7. Hi all, I just got here (well actually I've been lurking and learning from many of your posts here for a couple weeks), and I see there is an announcement about the MSFN closing in a month. That would be tragic. I gather that was a while ago, and as of now MSFN is apparently still alive. So that is good. Hope it stays that way. I am happy to have found a good community full of skilled people with lots of valuable knowledge and insight. I recently built a new PC, and while I have been sticking with win 7 on my other systems, I have some peripherals for the new build which are not fully compatible with anything below win 8. So I decided to try Win 10, hoping that the hackers had worked out solid methods of forcing it to behave by now. In trying to wrestle this monstrosity from MS into submission I found myself here, digging through some informative posts and finding bits and pieces of the puzzle. NoelC's post about scheduled tasks provided a very useful baseline for trimming these tasks, and I appreciated that it wasn't overzealous about disabling everything like many of the other resources I have found on other forums. Many other sources recommend disabling things that will break stuff. Might not be immediately obvious depending on your use case, or the breakage may not be catastrophic, but NoelC's list was a more conservative and better informed baseline than I had found elsewhere. This post showing up in a google search was the reason I found MSFN in the first place. Thank you NoelC! For anyone else trying to nail down Win 10's scheduled tasks, that post provides a good starting point. I'm sure many people here already know these tricks but for those who don't, you also might look up NirSoft's TaskSchedulerView which provides a much better interface (NirSoft offers a brilliant assortment of very powerful and completely free tools worth checking out). TaskSchedulerView doesn't force you to dig through the task scheduler directory hierarchy, provides search feature, and allows enabling and disabling multiple selections at once. It made it much easier for me to get a complete overview of scheduled tasks, and keep a concise record of changes I made. Also, if you use sysinternals' PsExec to launch TaskSchedulerView as "system" then it is possible to disable those stubborn tasks which can not be directly disabled with admin rights through normal means. For PsExec search for sysinternals' PSTools, then to launch an exe with system rights use -s and if the exe has a graphical interface use -i so for example. psexec64 -s -i "path\to\TaskSchedulerView.exe" Yeah, I know you all probably all knew all of that. I used to dig around tweaking XP, or 98. Been using win 7 for years now and it never required a great deal of tweaking. I am kind of a reluctant power user. I will get my hands dirty if I have to, but I would rather be working in photoshop or doing some solid modeling. I would rather stay almost completely on the creative side, rather than the technical side. The way computers have evolved though, catering ever increasingly to the lowest common denominator, I inevitably find myself having to work around technical issues, and I am just the kind of person that never gives up and always finds a way. Seems like Microsoft is determined to put a stop to people like me. People who insist on making our computers work the way we want them to, in order to best accommodate our own specific workflows. They are trying to lock everything down and take away our ability to configure our systems however we see fit. Since installing Win 10 I have been forced to do more tweaking than I have had to do in many years, so much of it is new to me. MSFN has been an invaluable resource. Sorry, this was just going to be an introduction post, but I'm afraid I have a tendency to go off on tangents, and I often get carried away with excessive detail. I'll stop now. Anyway, glad to meet all of you. Happy to become a part of the community. Hope we can keep MSFN alive for much longer than just one more month.
  • Create New...