@CHEF-KOCH no what i mean is that if you double click on a tweak category, this wil not for all categories apply all tweak groupes, there are some categories in which not all tweak groupes are internally marked as recomended and when double clicking such category some tweak groupes (middle column) will not be applied. EDIT: I think the next big todo will be improving the tweaks page ...
I have discovered today when installing a new windows server with priv10 that without granting an allow rule for PrivateWin10.exe, not priv10 service the tool couldn't send out UDP packets, not sure why that was. And I also noticed that not all sockets of the service were tagged as belonging to that service, I'm not sure why that is since some sockets were properly tagged, I will have to investigate that. Probably its related to some thread context information. I also know that on windows 7 it was never enough to grant wuauserv (windows update service) network access it was always necessary to plainly allow svchost.exe to access the internet. I presume because of some sockets wuauserv opened were not properly tagged as belonging to wuauserv :/ So apparently when creating a service its easy to mess up the tagging of sockets. Hence I'm considering for all services that are not hosted in svchost.exe drop the usage of service tag all together and always threat all sockets and create all rules as for the hosting process indiscriminately to its service tag. This approach should have no practical drawbacks while making the mechanism much more fail safe.
Windows bundles multiple services under one svchost instance. AFAIK it is possible to declare your service as type "Standalone", that way it would get one svchost instance of its own.
Any non MSFT service is a standalone service. AFAIK you even need some MSFT code signature to create a dll that would be hosted by svchost.exe So the hole mess of multiple services running under one process is a MSFT exclusive mayhame. The problems we've got is that you can use the "workaround" they implemented for the windows firewall on other service processes, and the workaround is buggy. Theoretically a software vendor could of cause have some own my_svchost.exe to host multiple services belonging to his application package, but in reality really no one does that.
First, the slow machine, still with 0.72, threw a hissy today: Eventlog entry #1: Code: Application: PrivateWin10.exe Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: System.UnauthorizedAccessException at System.Security.AccessControl.Win32.SetSecurityInfo(System.Security.AccessControl.ResourceType, System.String, System.Runtime.InteropServices.SafeHandle, System.Security.AccessControl.SecurityInfos, System.Security.Principal.SecurityIdentifier, System.Security.Principal.SecurityIdentifier, System.Security.AccessControl.GenericAcl, System.Security.AccessControl.GenericAcl) at System.Security.AccessControl.NativeObjectSecurity.Persist(System.String, System.Runtime.InteropServices.SafeHandle, System.Security.AccessControl.AccessControlSections, System.Object) at System.Security.AccessControl.NativeObjectSecurity.Persist(System.String, System.Security.AccessControl.AccessControlSections, System.Object) at System.Security.AccessControl.NativeObjectSecurity.Persist(System.String, System.Security.AccessControl.AccessControlSections) at System.Security.AccessControl.FileSystemSecurity.Persist(System.String) at System.IO.Directory.SetAccessControl(System.String, System.Security.AccessControl.DirectorySecurity) at System.IO.DirectoryInfo.SetAccessControl(System.Security.AccessControl.DirectorySecurity) at FileOps.SetAnyDirSec(System.String) at PrivateWin10.App.Main(System.String[]) Eventlog entry #2: Code: Faulting application name: PrivateWin10.exe, version: 0.72.0.0, time stamp: 0xea9a44fb Faulting module name: KERNELBASE.dll, version: 10.0.18362.476, time stamp: 0x121d258f Exception code: 0xe0434352 Fault offset: 0x001220d2 Faulting process id: 0xcbc Faulting application start time: 0x01d5b6a82341a60c Faulting application path: C:\Program Files\PrivateWin10\PrivateWin10.exe Faulting module path: C:\WINDOWS\System32\KERNELBASE.dll Report Id: 7281e697-488c-4e9d-85e3-2866c3885b0b Faulting package full name: Faulting package-relative application ID: Will try 0.72b next.
Results: Code: Microsoft Windows [Version 10.0.18362.476] (c) 2019 Microsoft Corporation. All rights reserved. C:\Program Files\PrivateWin10>PrivateWin10.exe C:\Program Files\PrivateWin10>Config Directory: C:\ProgramData\PrivateWin10 Log: PrivateWin10 Process Started, Mode Normal. Trying to connect to Engine... Trying to start service... Trying to connect to service... Connected to service... Log: TweakManager loaded 183 entries Your copy of this application is not activated Settign View Mode: NormalView UpdateProgramList took: 10907ms TestAllTweaks took: 28917ms Retrying gpo.Save() (1) Retrying gpo.Save() (1) Retrying gpo.Save() (1) Retrying gpo.Save() (1) Retrying gpo.Save() (2) Retrying gpo.Save() (3) Retrying gpo.Save() (4) Retrying gpo.Save() (5) Retrying gpo.Save() (1) Retrying gpo.Save() (2) Retrying gpo.Save() (3) Retrying gpo.Save() (1) TestAllTweaks took: 13416ms Retrying gpo.Save() (1) Retrying gpo.Save() (2) Retrying gpo.Save() (3) Retrying gpo.Save() (4) Toggled a few times back and forth. It did apply 16/17 tweaks, this time. I guess the 17th is not applied by design (Background Apps). All in all, looks a lot better. Maybe the timeouts could be made configurable?
Windows Internals Edition 6 Chapter 4 Service Tags [...] Windows implements a service attribute called the service tag, which the SCM generates by calling ScGenerateServiceTag when a service is created or when the service database is generated during system boot. The attribute is simply an index identifying the service. The service tag is stored in the SubProcessTag field of the thread environment block (TEB) of each thread (see Chapter 5, “Processes and Threads,” for more information on the TEB) and is propagated across all threads that a main service thread creates (except threads created indirectly by thread-pool APIs). Although the service tag is kept internal to the SCM, several Windows utilities, like Netstat.exe (a utility you can use for displaying which programs have opened which ports on the network), use undocumented APIs to query service tags and map them to service names. Because the TCP/IP stack saves the service tag of the threads that create TCP/IP end points, when you run Netstat with the –b parameter, Netstat can report the service name for end points created by services. Well £uck
meh... we need something better than timeouts, the proper approach would be not to cave each tweak individually but all of them in one go, but that would make the internal logic quite a bit more complicated.
Can you check that gui and service booth are allowed to full access. I think the issue you have may be related to the tagging problem I observed earlier.
Preview build with variouse fixes and improvements ## [0.73a] - 2019-12-19 ### Added - added greatly improved search edit box, focus with ctrl+f - added "del" keyboard short key to remove selected item ### Changed - reworked GPO handling to avoid write lock conflicts on slower machines ### Fixed - fixed an issue when clicking the tray icon before the main window was fully loaded - fixed access color not changing in program list view - fixed crash bug on start as on admin - fixed crash bug with app package name resolution - fixed issue when upon a change the ribbon controls were not updated acordingly
I tested 0.72b in my FAST Ring VM, too. This is build 19536.1000 Two errors on startup: 1. "Failed to initialize NetworkMonitorETW" (What does this one need to function?) 2. "Exception in GetIcon: Requested range extends past the end of the array." Will try with 0.73a soon.
How about PrivX if PWX is already taken? 0.73 did behave well (I only use tweaks) Will check out 0.74 next.