Updated the readme instruction for triggering early / system start of Windhawk service, which is necessary to ensure that classic theme is properly applied before any programs including Taskbar run. The mod code is same, only readme instruction has changed. Also added one more classic theme related mod to the recommended mods list in the readme.

[levitation]

Notes for the current solution:

• I checked the service start timings in different computers. In the computer where I have sometimes seen classic theme being applied too late, without using the solution in this readme version, Windhawk service was by default started over a minute later than Task Scheduler service was started.
• I created then a Task Scheduler task with "net start windhawk" command in it. This improved significantly the Windhawk service start delay. From the Task Scheduler log I can see that this task is triggered 2-3 seconds after the Task Scheduler service starts. Windhawk service in turn will start in about 15-20 seconds after the command in Task Scheduler.
• I checked also other services that start before Task Scheduler, to decide whether I could set Windhawk as dependency for any of them. When compared to these earlier services, Task Scheduler starts also quite early, only 3 seconds after the very first service starts. The earlier running services did not look clearly safe to set as dependent on Windhawk yet, I may investigate more in the future.
• I imagine that setting a service dependent on Windhawk would be mainly risky not because Windhawk would be unstable, but because of an additional risk that would arise - I have seen repeatedly that sometimes Antiviruses randomly and silently remove executables they do not like. This happens even if they are configured to ask for confirmation. Windhawk can easily become such a target.
• One alternative idea popped to my mind that we can explore in the future. We can set Windhawk as Debugger for explorer.exe in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options - but to do that, Windhawk needs to support being a "debugger", else explorer.exe would not be launched and only Windhawk would start. For example, https://github.com/gexgd0419/EdgeWindowTabManagerBlock uses such technique for intercepting the launch of Edge processes. The relevant lines seem to be 400 - 414 in the file source.cpp: https://github.com/gexgd0419/EdgeWindowTabManagerBlock/blob/c1df705b1117d177e6a0b20383fc3254ef585f02/EdgeWindowTabManagerBlock/source.cpp#L400
  There are then two different potential use cases with this approach:
  1. The current use case is to start Windhawk service and run all the mods and inject them into already running processes, before continuing the start of explorer.exe
  2. An additional interesting use case is to use Windhawk as a "debugger" to intercept the start of any specified program so that Windhawk can hook into the process immediately when the process starts.

[m417z]

• I checked also other services that start before Task Scheduler, to decide whether I could set Windhawk as dependency for any of them. When compared to these earlier services, Task Scheduler starts also quite early, only 3 seconds after the very first service starts. The earlier running services did not look clearly safe to set as dependent on Windhawk yet, I may investigate more in the future.

FYI, I saw somebody on Discord recommending to make ProfSvc depend on Windhawk. I didn't try it, but it worked for them.

• I imagine that setting a service dependent on Windhawk would be mainly risky not because Windhawk would be unstable, but because of an additional risk that would arise - I have seen repeatedly that sometimes Antiviruses randomly and silently remove executables they do not like. This happens even if they are configured to ask for confirmation. Windhawk can easily become such a target.

I'm not sure how an antivirus is a problem in this case. Why is it different from adding it via a schedued task?

I like the dependency way more because it's more predictable - the service that depends on Windhawk will wait for Windhawk to run. With a scheduled task, Windhawk starts asynchronously, which means that the load order is not guaranteed and may wary between boots.

• One alternative idea popped to my mind that we can explore in the future. We can set Windhawk as Debugger for explorer.exe in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options [...]

Explorer launches much later than services, most of which start even before the user logs in.

[Anixx]

If you want to start anything before the shell, you should replace userinit in registry, as said in point 6 in this tutorial: valinet/ExplorerPatcher#167

[levitation]

• I checked also other services that start before Task Scheduler, to decide whether I could set Windhawk as dependency for any of them. When compared to these earlier services, Task Scheduler starts also quite early, only 3 seconds after the very first service starts. The earlier running services did not look clearly safe to set as dependent on Windhawk yet, I may investigate more in the future.

FYI, I saw somebody on Discord recommending to make ProfSvc depend on Windhawk. I didn't try it, but it worked for them.

@m417z I now added an additional instruction for making a service dependent on Windhawk. I chose a service that seemed least disrupting, in case Windhawk does not start. Bear in mind, if Windhawk does not start then the dependent service will not start either. ProfSvc not starting means the user will not be able to log in. With some services failing the system will not connect to internet, or will even reboot. Right now I chose Plug and Play service.

I hope with that addition the instruction is sufficient both for more conservative people as well as for more risk tolerant ones.

• I imagine that setting a service dependent on Windhawk would be mainly risky not because Windhawk would be unstable, but because of an additional risk that would arise - I have seen repeatedly that sometimes Antiviruses randomly and silently remove executables they do not like. This happens even if they are configured to ask for confirmation. Windhawk can easily become such a target.

I'm not sure how an antivirus is a problem in this case. Why is it different from adding it via a schedued task?

If Windhawk is a scheduled task then failure of Windhawk will not affect any services.

I like the dependency way more because it's more predictable - the service that depends on Windhawk will wait for Windhawk to run. With a scheduled task, Windhawk starts asynchronously, which means that the load order is not guaranteed and may wary between boots.

• One alternative idea popped to my mind that we can explore in the future. We can set Windhawk as Debugger for explorer.exe in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options [...]

Explorer launches much later than services, most of which start even before the user logs in.

1. I assure you, I made repeated measurements. There are nuances which turned out to be different from our assumptions. Explorer and other programs can start before the user logs in. That is why I added the instruction about "Sign-in options".
2. My point was that if Windhawk were set as a debugger for explorer, then that would serve the desired purpose entirely. It does not matter whether Windhawk and explorer both start late. As long as Windhawk starts before explorer, the classic theme will be applied on time since explorer is the one who will start the rest of startup apps.

[levitation]

If you want to start anything before the shell, you should replace userinit in registry, as said in point 6 in this tutorial: valinet/ExplorerPatcher#167

@Anixx This is interesting. I imagine, if we used this method, then Windhawk or classic theme mod would still need to support it. The thing is that if Windhawk starts from this script, then I imagine that the script will continue loading the shell process immediately after starting Windhawk, since currently the script does not know when the Windhawk actually started up and is ready to do its work. Am I correct? In order to avoid this race condition, Windhawk itself would have to trigger the start of explorer when it is actually ready. But this means Windhawk or for example the classic theme mod in Windhawk would need to support such a chain. The upside of your proposed approach is that the code of Windhawk does not have to be necessarily changed, the change could be done also inside the mod code.

[levitation]

@m417z Hey, discovered an additional detail about making services dependent on Windhawk, which you might want to keep in mind when you use this strategy yourself.

Namely, if I need to manually stop Windhawk service temporarily, then that will automatically shut down the dependent service as well.

Manually stopping Windhawk happens more often than antivirus removing it. Because of that it is even more important that the stopping of dependent service does not break anything immediately. My current choice of Plug and Play service seems to be quite safe choice in that regard as well. In contrast, for example stopping ProfSvc might be problematic.

(Also, I did not mention it before, Plug and Play service as a dependent service makes Windhawk start before any services start).

[m417z]

Good to know, thanks for the update. I'm not too familiar with the services to judge which is more troublesome to have broken, but "does not break anything immediately" is something :)

[teknixstuff]

@m417z Hey, discovered an additional detail about making services dependent on Windhawk, which you might want to keep in mind when you use this strategy yourself.

Namely, if I need to manually stop Windhawk service temporarily, then that will automatically shut down the dependent service as well.

Manually stopping Windhawk happens more often than antivirus removing it. Because of that it is even more important that the stopping of dependent service does not break anything immediately. My current choice of Plug and Play service seems to be quite safe choice in that regard as well. In contrast, for example stopping ProfSvc might be problematic.

(Also, I did not mention it before, Plug and Play service as a dependent service makes Windhawk start before any services start).

Shouldn't disabling plug-and-play service also break external devices? That could be quite a problem, especially if you had an external wifi card or similar essential devices externally. Stopping ProfSvc only prevents logins to non-admin accounts, which isn't too bad. Additionally, Windows will wait for ProfSvc before beginning the login process, ensuring windhawk can start as early as possible.

[levitation]

@m417z Hey, discovered an additional detail about making services dependent on Windhawk, which you might want to keep in mind when you use this strategy yourself.
Namely, if I need to manually stop Windhawk service temporarily, then that will automatically shut down the dependent service as well.
Manually stopping Windhawk happens more often than antivirus removing it. Because of that it is even more important that the stopping of dependent service does not break anything immediately. My current choice of Plug and Play service seems to be quite safe choice in that regard as well. In contrast, for example stopping ProfSvc might be problematic.
(Also, I did not mention it before, Plug and Play service as a dependent service makes Windhawk start before any services start).

Shouldn't disabling plug-and-play service also break external devices? That could be quite a problem, especially if you had an external wifi card or similar essential devices externally. Stopping ProfSvc only prevents logins to non-admin accounts, which isn't too bad. Additionally, Windows will wait for ProfSvc before beginning the login process, ensuring windhawk can start as early as possible.

Stopping Plug and Play only prevents installation of new devices. Existing devices continue working.

I think it is subjective to say that blocking non-admin accounts is unimportant. Your grandma may disagree :P And some people say that running users under admin accounts is generally less safe practice.

Also, I have not personally verified that this is true that only non-admin accounts are blocked. I am wondering, why would that be the case that admin accounts still continue working? Unfortunately I have no time to verify this at the moment. Definitely an interesting detail to keep in mind though.

[teknixstuff]

@m417z Hey, discovered an additional detail about making services dependent on Windhawk, which you might want to keep in mind when you use this strategy yourself.
Namely, if I need to manually stop Windhawk service temporarily, then that will automatically shut down the dependent service as well.
Manually stopping Windhawk happens more often than antivirus removing it. Because of that it is even more important that the stopping of dependent service does not break anything immediately. My current choice of Plug and Play service seems to be quite safe choice in that regard as well. In contrast, for example stopping ProfSvc might be problematic.
(Also, I did not mention it before, Plug and Play service as a dependent service makes Windhawk start before any services start).

Shouldn't disabling plug-and-play service also break external devices? That could be quite a problem, especially if you had an external wifi card or similar essential devices externally. Stopping ProfSvc only prevents logins to non-admin accounts, which isn't too bad. Additionally, Windows will wait for ProfSvc before beginning the login process, ensuring windhawk can start as early as possible.

Stopping Plug and Play only prevents installation of new devices. Existing devices continue working.

I think it is subjective to say that blocking non-admin accounts is unimportant. Your grandma may disagree :P And some people say that running users under admin accounts is generally less safe practice.

Also, I have not personally verified that this is true that only non-admin accounts are blocked. I am wondering, why would that be the case that admin accounts still continue working? Unfortunately I have no time to verify this at the moment. Definitely an interesting detail to keep in mind though.

Windows has a special case to ensure admins can log on even if the user profile service breaks, since someone needs to be able to log in to fix it. It does give you a balloon about the issue telling you to fix it when you log in though.