Wininit Warning message on every boot/reboot.

A. The bug/issue

  1. What you did:Boot/Reboot.
  2. What actually happened or you actually saw:Warning (attached) in System Log (Event Log).
  3. What you expected to happen or see:No Message.
  4. How you tried to fix it & what happened:Turned off LoadAppInit_DLLs bit in Registry. No more error message, but does this affect running of CIS???
  5. If its a software compatibility problem have you tried the compatibility fixes (link in format)?:N/A.
  6. Details & exact version of any software (execpt CIS) involved (with download link unless malware):N/A.
  7. Whether you can make the problem happen again, and if so exact steps to make it happen:Boot or reboot.
  8. Any other information (eg your guess regarding the cause, with reasons):CIS is leaving the AppInit information in the Registry.

B. Files appended. (Please zip unless screenshots).

  1. Screenshots of the Defense plus Active Processes List (Required for all issues):N/A.
  2. Screenshots illustrating the bug:System Logs (2).
  3. Screenshots of related CIS event logs:N/a.
  4. A CIS config report or file.N/A.
  5. Crash or freeze dump file:N/A.
  6. Screenshot of More~About page. Can be used instead of typed product and AV database version.N/A.

C. Your set-up

  1. CIS version, AV database version & configuration used:5.10.228257.2253/11929/ProActive.
  2. a) Have you updated (without uninstall) from from a previous version of CIS:Probably.
    b) if so, have you tried a clean reinstall (without losing settings - if not please do)?:Yes.
  3. a) Have you imported a config from a previous version of CIS: No.
    b) if so, have U tried a standard config (without losing settings - if not please do)?:N/A
  4. Have you made any other major changes to the default config? (eg ticked ‘block all unknown requests’, other egs here.):No.
  5. Defense+, Sandbox, Firewall & AV security levels: D+= , Sandbox= , Firewall = , AV = All N/A.
  6. OS version, service pack, number of bits, UAC setting, & account type:W7 x64 Ultimate+SP1+all critical Updates.
  7. Other security and utility software currently installed:None.
  8. Other security software previously installed at any time since Windows was last installed:None.
  9. Virtual machine used (Please do NOT use Virtual box):The problem is present in a VM (VMware Player).

This is a duplicate to[url=https://forums.comodo.com/format-verified-issue-reports-cis/comodo-firewall-guard64dll-event-id-11-wininit-nbz-t69441.0.html] https://forums.comodo.com/format-verified-issue-reports-cis/comodo-firewall-guard64dll-event-id-11-wininit-nbz-t69441.0.html[/url]. Please look at the information I have added at the end. I have replied to the original Bug report, opened a Help thread and PMed mouse1 with no response, so I am opening a duplicate problem since the problem is clearly not been addresed. Please correct this problem. It may well go deeper that just an error warning message. The link provided in the original Bug report indicates the person reporting a (non-CIS) problem got a significant reduction in boot time correcting it. Thanks and enjoy, John.

EDIT: Added screen shot of SystemsInternals AutoRuns AppInit tab.

[attachment deleted by admin]

Sincere apologies for lack of response to PM. Missed this somehow.

Travelling down to see seriously ill relative very early tomorrow (my wife’s aunt), so will deal with this on my return on Friday if that is OK. (Or another mod may respond before this).

Best wishes

Mouse

Mouse, sorry to hear of your family problems and hope things work out for the best.
There is no hurry at all on this problem. Thanks, John.

Sorry deleted mis-post, which was based on my misunderstanding.

And thanks for bearing with me yesterday.

I can merge this post with your former bug report if you like, which will have the effect of reminding people of this problem.

Maybe it has not been addressed because the settng in this case is intentional, to ensure all programs load guard64.dll?

In which case it would not be wise to disable it.

The event is just a warning event which users can [edit] maybe safely ignore. The boot delay may be a necessary consquence of the loading of CIS.

I can replicate this myself. I have exactly the same OS as you.

I could ask for a dev comment if you like - though I cannot guarantee one.

Best wishes

MOuse

Thanks, Mouse for your reply. Don’t know what you are referring to about a deleted mis-post. The other post concerning this problem is not mine; I just replied to it. I did not know how to deal with the continued occurring of a problem when the Bug report had no fix or real response. My reply is duplicated here so all the information, from my view, is in one place:

This Warning message is caused by LoadAppInit_DLLs being set to 1 in the Registry. Please see this thread->Redirecting for an explanation that is similar. The difference is that CIS is does have an entry for AppInit_DLLs. Testing on a VM (VMware Player) comfirms that turning off the LoadAppInit_DLLs does stop the warning message. The problem for me is that I do not know if this adversely effects CIS. After turning it off I still see plenty of Guard32 and Guard64 DLLs present on a Process Explorer DLL display. Is it OK to turn off this bit in the Registry? If so, then Comodo should not leave it set. Thanks and enjoy, john.
I do not think this is an x64 only problem as both Guard64 and Guard32 show in the Registry. Please see the AutoRuns screen shot I added to my first post in this thread. As I stated in my reply to the original thread, I tried turing off the LoadAppInit_DLLs (no warning message) but there were many references to the two Guard DLLs. I think the developers need to look at this. It appears, to me, that this information has been left in the Registry by mistake. I think that is what Windows is complaining about and suggesting that the system analyst needs to correct. I am asking that it be corrected. Thanks much and enjoy, John.

OK I will probably merge as its not helpful to devs to have two reports on one problem. Yours will act to remind and reinforce.

Could you tell me why you think it’s been left behind in error? It seems sensible that the devs would want to insist that guard64/32 etc was always loaded. Is it just that guard32/64 seem to load in some apps anyway? Or is it more than this. Possibly I did not fully understand the link, which seemed to be saying that the setting involved was about ensuring that loading always occurred for all apps?

Many thanks for the report anyway, BTW, much appreciated :slight_smile:

Best wishes

Mouse

Thanks again, Mouse. I will admit I do not understand what these settings do. The fact that Windows is complaining about it on every boot tells me it is not normal. The fact that I see many Guard32 and 64 DLLs loaded after turning off the bit leads me to believe it is no longer needed. Of course, I could be wrong and it may well be needed. Then why does Window insist on complaining? I think to get this answered, we need to have a developer look at the problem and tell me what to do. I will be glad to create a .reg file to change the Registry settings as they should be, assuming I am causing no harm, when I install CIS on a new system install (I do frequent Windows installs using an unattended process). Now some procedural questions. Why is there no response to the old problem I replied to and pointed to here? Is there a way to check the status of a problem - tracking system? Will I get some response to this bug report? Thanks and enjoy, John.

It may be that this is just a security warning, mis-classified as a system warning. But I agree we do not know, so it’s valid to ask.

I think to get this answered, we need to have a developer look at the problem and tell me what to do. I will be glad to create a .reg file to change the Registry settings as they should be, assuming I am causing no harm, when I install CIS on a new system install (I do frequent Windows installs using an unattended process). Now some procedural questions.
Ok I will request.
Why is there no response to the old problem I replied to and pointed to here? Is there a way to check the status of a problem - tracking system? Will I get some response to this bug report? Thanks and enjoy, John.
Personally I, and I think many otrher mods believe that it would help Comodo if devs responded more and kept reporters of bugs up to date. Unfortunately it has proved difficult to cause this to happen. (Please note mods are not Comodo employees, so we cannot really do more than suggest). The likely reason is that interaction with users is very time intensive, and CIS as free software does not have a huge development budget. THere are some fixes listed with every release, so that is of some help, but this list is not very detailed.

Regarding tracking systems there were two. A developers tracking system and a mods tracking system. The developers tracking system still exists but we have not access to it. The mods tracking system has not been used greatly recently as feedback from devs was pretty infrequent, it was awkward to use (outdated and very busy bugzilla interface), and it was not integrated with the forum (requiring duplication) so those mods that were contributing eventually got discouraged. I had to give up during a family crisis (my mother was seriously ill and then died), and I guess that that was the final straw as I was contributing most bug reports. Because of all the other problems with the system and dev feedback the mods system seemed to lose momentum while I was unavoidably away from the forum, a fact I feel rather guity about. I have been thinking of restarting it, but…

We have recently discussed with devs a web form-based submission system with automatic data collection, and some mod and user access, and we think Comodo maybe going to do this. So I’m holding fire for the present to see what happens.

The known issues list is perhaps fairly helpful for tracking the most important bugs, and I do try to keep this up to date. But without detailed info on fixes this is difficult.

Hope this helps explain a little even if it does not excuse the lack of a more visibly systematic approach.

Best wishes

Mouse

Thanks, Mouse. I appreciate the explanation of the process. Thanks for requesting for the developers to look at this. We’ll just have to see what comes of it. I would hope I could at least learn if it is OK to turn off the LoadAppInit_DLLs bit without harming CIS function. Thanks and enjoy, John.

Please do not disable anyting. CIS requires those Appinit-DLLs functions for proper functioning under certain circumstances. This is not an important warning.

OK, egemen thanks. I will not disable this function. After doing more research and reading this description (Windows Hardware Dev Center Archive - Windows 10 hardware dev | Microsoft Learn) of what this mechanism does and how it operates, I agree it is needed and the Warning message can be ignored. Thanks and enjoy, John.

Thanks for responding Egemen, much appreciated.

@Johnc: I’ll forwards this and the duplicate to resolved if that’s OK with you.

Best wishes

Mouse

Mouse, I agree. I have some more ideas here to investigate, but will comment elsewhere if I come to any rational conclusion. Thanks and enjoy, John.