Morning!! In event viewer somehow code integrity logs weren't populating when being checked. At boot time I got a BSOD on this machine with the notorious DPC_WATCHDOG_VIOLATION message. I ran DISM and checked the install image, after which I DID find the log entries for event ID: 3033 had indeed been logging for over 2 months. Obviously previously hidden. I have determined that "SIHClient.exe" IS making calls to symamsi.dll, the entries are numerous on this system BUT, are all the same. SIH is Microsoft Silent Install Helper most likely running to attempt resolving the code signing issue.
Sending this up to the team yet again to see what action we can get. I'm betting as you are as well, this error is prevalent on most installs of Norton and not being see via a Windows notification. Therefore, the secenario it, its out of sight out of mine.
Hello, I have checked my event viewer, and can see fresh event 3033 against Norton Security\Engine\22.20.5.39\symamsi.dll.
I have attached a typical one. I also see EVENT ID 12, from Defender doing similar checks.
These are after the R&R as suggested. Hopefully Norton Admins will pick this up, and we will see a fix soon. It would be nice to see them concentrate on the "core" product, rather than other stuff (PC performance, VPN advert pushes...)
Hello again thanks for the post back. The code signing / digital signature dates being expired IS a Norton issue which I have reported to them for escalation. As I also have in the other thread where there are other dll files with expired certificate dates. Norton has in the past just corrected an issue such as this with an update that is delivered within live updates or re-installation media. The issue gets corrected and no one ever knows the better. Most instances a remove only scenario then a clean reinstall of Norton will correct things.
Yesterday, I had to do a removal only then a clean reinstall on my one machine that runs N360 Deluxe due to an older VPN issue having reappeared. I've checked for the certificate dates on symamsi.dll. They are the same as before. The R&R DID clear my issue.
Please let us know what your event logs are telling you after the clean reinstall.
Hi @SoulAsylum - I did he R&R, however, I did not realise that the "remove only" was under the advanced tab. I was a bit tired last night, and missed that. I chose the normal R&R tab, and It did a full remove and re-install though. However, it seemed to reset the new install with defaults, so I had to add back in my settings change password, and Full Scan schedules.
I was rather disappointed that it ALSO removed my own added Firewall Traffic site specific IP address blocks, that I have built up over time, where my Router Logs show many Chinese, Romanian, RU and other suspect country sites doing port scans. This is just in case they happen to get in by other means (although my Billion router has very good security, and there should not be any open ports facing The Internet). I DO have the blacklist as a text file, but it will be an hours work at least to add these 100 or so entries back in.
I have not yet had chance to check out the Event Logs after that re-install, but I wanted to give it 24 hours or so anyway before checking those. I will report back tomorrow.
By the way, in your previous post of 22nd NOV, you stated that "This is a Norton issue for them to resolve", so I was wondering why you have now reverted back to asking me to do this R&R??
Hello again. Lets do a R&R on your Norton install and perform a "removal only" scenario. Scroll down to the section labeled "Remove Norton device security completely" and do a remove only scenario. Reboot.
After the reboot download a FRESH installer by signing into your Norton account. Download the installer to your desktop and close your browser. Run the downloader as admin. Install your Norton product. Then get all the patches available. As each patch completes install reboot whether prompted for that or not. Finish patches and remaining update in the same manner and reboot one final time. Lets check to see if these issues persist.
FYI: I have just noticed another EVENT ID logged for the NORTON symamsi.dll. This time it is EVENT_ID 12, for KERNEL MODE Security-Mitigations, for a check by Windows Defender. I have uploaded the full event text. Summary:
"Process '\Device\HarddiskVolume1\Program Files\Windows Defender\MsMpEng.exe' (PID 8024) was blocked from loading the non-Microsoft-signed binary '\Program Files\Norton Security\Engine\22.20.5.39\symamsi.dll'. "
Hi @SoulAsylum - thanks for that useful observation, and please do bump to Norton Admins as you see fit. It sounds like it might be useful to others getting similar code signing issues, if you have seen similar threads. Thanks for your help so far, much appreciated.
One thing I totally missed from your original post was SIHClient.exe which is "Service Initiated Healing" client in Windows 10. Usually it loads to fix things such as Windows Update stores and other Windows components that are corrupt. Code integrity will also flag "unsigned" processes as it did with symamsi.dll, this is a NORTON issue for them to resolve. Other outdated / unsigned Norton files were found and are in other threads which ATM I cannot find links for. Allow me to bump this to the team for action and report back. Hopefully an Admin will get in on the thread as well.
I am not using Windows Hello, I have NO Biometric devices, and I am not using BitLocker or any other Device Encryption.
The MOBO is a (rather old) ASROCK Z68 Pro3 M with an Intel i3 and 8GB memory. The install is using BIOS mode not UEFI (although the MOBO has UEFI). It has been really stable from day 1, and as I am not a gamer, I saw no reason to upgrade it yet, or add in any fancy Graphics card.
Not having TPM shouldn't have any bearing on code signing enforcement at all. Windows Hello can, as a software solution also be the cause of certain issues is the absence of TPM. Do you use Windows Hello? Biometric device? Device encryption support? Who makes your MOBO and what is its model? I'd like to have a look at its hardware and security features to see what is what.
Hello again @SoulAsylum - apologies - being an old retired Mainframe SysProg (and not a modern developer) I did not realise how Code Signing Certs worked, and I was making sime assumptions. I got this from the Digicert site:
"Digicert timestamp services allow you to timestamp your signed code. Timestamping ensures that code will not expire when the certificate expires because the system validates the timestamp. If you use the timestamping service when signing code, a hash of your code is sent to the timestamp server to record a timestamp for your code.
A user’s software can distinguish between code signed with an expired certificate that should not be trusted and code that was signed with a Certificate that was valid at the time the code was signed but which has subsequently expired."
Is it likely that not having an active TPM setup in my "self-build" system is affecting the way that the "code integrity" OS Kernel functions are checking key items of AV code? I feel that I should NOT be seeing this "symamsi.dll did not meet the Windows signing level requirements" error message though.
Hello @SoulAsylum thanks for your input and suggestions. I am NOT using Device Guard.
I have had a look at the SHA1 and SHA256 certs for this DLL. The odd thing is that the SHA256 one had an end date of 26/3/20. and the SHA1 cert ended 21/1/20. So these are both now out of date, although the UI states the "Digital Signature is OK" for both.??
Am I assuming correctly from your R&R suggestion, that level updates of my Norton product (i.e. when I get one of those 120MB+ downloads), do NOT update ALL of the product modules, to cater for Bug Fixes/Enhancemnts AND expired Digital Certificates (but going to the full install on the web-site WILL update everything)?
If so, I am not sure that is very good practice (to show a valid product level, but have down-level CERTS for older modules not updated in the product).
As a further bit of info (that MIGHT be relevant), the Motherboard in this desktop PC is a "self-build" so does NOT have the TPM set up. Your system may well be a "Manufactured brand" with all the OEM/TPM data set up, so possibly the ."NCrypt Operation" services in the Windows 10 OS are working differently. Ift is possible that this is making an "assumption" that TPM is active, and checking the Symantec AV on behalf of security kernel Drivers differently than when TPM is actually active.
Either way, even YOUR certificate shows an expired date, so I am unsure if a R&R will have ANY effect on this issue.
Helo td47. I don't see any of the event ID 3033 entries in my event manager on this machine. Running the same version of 20H2 that you are using, Windows 10 Prop x64. Opening the properties for the symamsi.dll I see the following which shows the certificate is valid for that process. The only way to correct the certificate signing issue is perform an R&R of your Norton product, preferably a remove only scenario. Reboot fully then reinstall your Norton product from your Norton account.
Do you have device guard enabled on your system under Group Policy? If so that is the possible cause of the event ID 3033 issue being logged.
Cheers
Do you have