guard64.dll- hashes of an image file are not valid

Hi PremJK,

File link was sent in response to your private message.

My System is: Windows Pro 10(x64) version 1803 Compilation 17134.165

att

Hi Picandalo,

Thanks for providing requested logs. We forwarded logs for investigation.

Kind Regards,
PremJK

This is a long standing issue that occurs because comodo doesn’t add guard64.dll to a signed security catalog that contains its hash.

1 Like

futuretech
But then what is the solution to this? … should I ignore the error message? … both the System and the CIS will not be affected by this?

P.S:
another thing, plus a questioning for PremJK or futuretech

I created another post on CIS not being able to recognize windows system files and one of the options given was to install a beta version of CIS.

I can not install beta versions because I use my PC for work and the CIS version I’m using does not recognize the Windows files yet!

It is very unpleasant having to, at all times, release the System files not recognized in the CIS.

When will this situation be resolved? … I’m almost uninstalling Cis and returning to Windows Defender.

Att

Yes you can ignore these warnings as it does not affect anything. Unrecognized files is a visual bug only and files are still treated as trusted, you will have to wait until they release a finial build due sometime at or before the end of this month.

futuretech,

Ok thanks for the information and I will be waiting for the release of the visual bug fix.

regards
Picandalo

Knock, knock. This issue is still present with the newest Windows 10 and current CIS. Just to let you know.

I am seeing a lot of variations on this in Event viewer -
Process …Windows\System32\dllhost.exe’ …was blocked from loading the non-Microsoft-signed binary ‘\Windows\System32\guard64.dll’
Wondering how serious it is (& if it needs to be fixed or is relevant), as I am finding CIS is clashing with Opera.
Opera wasn’t whitelisted when I did the last prog update & it keeps crashing, sometimes needing a hard reset to recover the PC.
I noticed that on reboot W10 claims the AV is out of date - CIS dialog says 1 month - I then re d/l & re-install the update & on the next crash the AV update db reverts from xx hr to 1 month.
I suspect CIS doesn’t like the Opera update operation, but generally speaking I’d like to rule out CIS from my potential trouble list.

Looks really bad. Error still present. Fresh install on Win10.

This is an older topic. The events logged by Windows simply tell that the way guard64.dll gets loaded is deprecated by Microsoft. It is not a risk security or otherwise.

1 Like

Win10Home (v. recent clean install)
Defender AV
Comodo Free FW 12.0.0.6818

I’m aware that there have been many posts on this topic before over the years (esp. with regard to guard64.dll), but not (as far as I am aware) concerning cmdagent.exe as well.

MS Windows security auditing is constantly reporting (as seen in Event Viewer) “Code integrity determined that the image hash of a file is not valid…” for both the afore-mentioned modules.

cmdagent.exe appears to get reported on once per boot

guard64.dll is reported on all the time at irregular intervals.

If this is a known issue ( as per https://forums.comodo.com/news-announcements-feedback-cis/comodo-internet-security-2019-v12006818-ndash-released-t124172.0.html;msg887680#msg887680 reply #43 (“Those errors can be ignored as it is just Windows complaining it doesn’t have the security catalog information for guard64.dll”), why is nothing being done about it?

It seems incongruous, to say the least, for security software to not be addressing something that is a security concern (even if it is a false positive or other erroneously reported issue).

I am having the same issue. Product version 12.0.0.6882. My event log is full of errors in section Audit Failure:


Code integrity determined that the image hash of a file is not valid.  The file could be corrupt due to unauthorized modification or the invalid hash could indicate a potential disk device error.

File Name:	\Device\HarddiskVolume2\Windows\System32\guard64.dll

141 errors in just an hour and counting …

Please don’t kick old topics. It is not needed. You already have two other posts in recent topics. That is enough exposure. More posts about this will be seen as needless cross posting.

Hi

The Windows System log is experiencing the following audit failure:
Date: 2020-05-19 12: 01: 15.843
Description:
Windows is unable to verify the image integrity of the file \Device\HarddiskVolume2\Windows\System32\guard64.dll because file hash could not be found on the system. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source.

How to proceed to repair the guard64.dll file, so that windows can recognize it… or is this not a bug?

thank you

The reply from before - so just ignore it. It is not an error in any case; just information that’s shown

Ok Ploget,

Very thank’s
Picandalo

Not a bug as it does not affect CIS operation.

Code integrity determined that the image hash of a file is not valid. The file could be corrupt due to unauthorized modification or the invalid hash could indicate a potential disk device error.

File Name: \Device\HarddiskVolume11\Windows\System32\guard64.dll

(taken from Manage Computer>Event Viewer>Windows Logs>Security)

Uninstalled, Re-Installed, no change.

Any solutions?

EDIT:

sfc /scannow
Microsoft Windows [Version 10.0.17763.1397]
(c) 2018 Microsoft Corporation. All rights reserved.
C:\Windows\system32>sfc /scannow

Beginning system scan.  This process will take some time.
Beginning verification phase of system scan.
Verification 100% complete.
Windows Resource Protection did not find any integrity violations.

EDIT2: The amount of logged Audit Failures are ENORMOUS in the logs (on the order of seconds). With no way of “ignoring” this for now I can’t imagine polluting the security logs is wise.

It cam be ignored: See here: Guard64.dll

I’d like to but the Windows Security log is an important aspect of insuring all’s well. I would hope that Comodo understands that having these spurious logs drown out the “real” stuff is problematic.