Checking my Windows 10 version 19042.630, I see regular event ID 3033 (from the event log) due to a signing level integrity issue for one of the Norton Security modules (symamsi.dll ). There have been over a thousand of these for the last month.
SUMMARY:
Code Integrity determined that a process (\Device\HarddiskVolume1\Windows\System32\SIHClient.exe) attempted to load \Device\HarddiskVolume1\Program Files\Norton Security\Engine\22.20.5.39\symamsi.dll that did not meet the Windows signing level requirements.
My Norton is Norton Security, version 22.20.5.39, running on Windows 10 version 19042.630 (20H2).
A text file sample of one event is attached for your review.
I have just installed the latest product update (Via LU), to my Norton Security. Sadly, there has STILL been no solution to the reported issue. Before any one asks, I DID reboot to ensure all valid updated objects were in place, and in memory as required.
Here is the usual Event 3033 in all its glory!:
“Code Integrity determined that a process (\Device\HarddiskVolume1\Windows\System32\svchost.exe) attempted to load \Device\HarddiskVolume1\Program Files\Norton Security\Engine\22.21.5.44\symamsi.dll that did not meet the Windows signing level requirements.”
So, has Norton just ignored this, and do not see it as an “issue”? I am very annoyed that over 7 months down the line, there has been NO input or resolution from Norton.
@SoulAsylum - thanks for quick response. You may have a point with the "Feature Bit". However, where you have been looking is two levels too deep, so if you go up to the AMSI key, you should see the DWORD value in there, and it is typically a "1". It IS there in both my Win10 PRO and my Win10 HOME systems.
It is always possible of course, that Norton are getting this wrong, and the "FeatureBits" DWORD value SHOULD appear under its own GUID for its product, as POSSIBLY if a user has TWO AV products installed, they may want, or need, 2 different values? That is normally frowned upon, for conflict and performance reasons. I DO actually run the MWB (MalWareBytes) "AV" alongside the Norton Security (mainly because of the dynamic Ransomware protection), but I don't think it actually has an "AMSI" object it needs to register, so that is why I only see ONE GUID under the AMSI "umbrella".
Maybe Microsoft is unclear in their DEV documentation for AMSI providers, OR Norton have misinterpreted the requirements. All I know right now, is that I have an irritating issue that has gone on for FAR too long, and I just want it fixed.
Thanks for the post back. I think this statement from your link has nailed the issue:
Important
Even though the Windows Registry value is not protected by the operating system, your computer's antivirus provider might protect the value, thus making it write-protected.
The registry value "Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AMSI\FeatureBits" is not present on any of my machines.
Edited: The laziness of incorrect coding also begins here: https://docs.microsoft.com/en-us/windows/win32/api/unknwn/nn-unknwn-iunknown
@SoulAsylum thanks for your interseting feedback. I been checking my Event Logs again since the last Norton update:
So, I have now got Norton Security version 22.21.3.48, and I am STILL getting this clutter and garbage in my Event Logs (lots of them):
EVENT ID 3033:
"Code Integrity determined that a process (\Device\HarddiskVolume1\Windows\System32\SIHClient.exe) attempted to load \Device\HarddiskVolume1\Program Files\Norton Security\Engine\22.21.3.48\symamsi.dll that did not meet the Windows signing level requirements."
Plus many EVENT ID 12 (Security-Mitigations) still:
Process '\Device\HarddiskVolume1\Program Files\Windows Defender\MpCmdRun.exe' (PID 13020) was blocked from loading the non-Microsoft-signed binary '\Program Files\Norton Security\Engine\22.21.3.48\symamsi.dll'."
I looked at some AMSI documentation, and found this:
"Note As a provider, you must use the /ac switch (with the SignTool) to cross-sign with an Authenticode certificate. Once you've signed your binary, you can then verify it by using the SignTool and the /kp option. If the SignTool returns no error, then your binary is properly signed."
With that info above, I am leaning towards these Event 12 and 3033 issues (maybe even your 3089 event) as being a failure of Norton to properly use the /ac switch with the latest version of the signing tool, to ensure that the Microsoft AMSI police unit don't thow a hissy fit about it! So, it looks like most posters on here see the problem as firmly STILL in Norton's court to get fixed, and NOT Microsoft, that are just using their OS to affirm their good security stance on proper Authenticode configured AMSI executables.
As far as I am concerned, they have 139 days to fix this. or the Subscription renewal will wither on the vine, like a bad grape!.
@td47 I went back to one of your earlier posting and went off into another avenue with it. SIHclient.exe is called on by numerous shared libraries in Windows and third party software installs. One microsoft article even went so far as suggesting Access 2010 was the culprit, and removal/reinstallation was the key solution. I didn't bite on that one one bit. I did find this article, suggestive that Credential Guard may be the culprit. Opening my system info viewer I see the following running as highlighted: Note: I do NOT run any VM's on the machine in question, I DO dual-boot with Linux Mint.
Windows Defender application Control also came into mind and that too quickly faded since I do not have the hardware based security enabled nor is it supported.
I was doing some further research a day or so ago ( I forgot to keep the URL links to ), which suggested the expired certificates remain in place within Windows for the sake of backward compatibility issues. Going forward, Microsoft has gone strictly to SHA-2 and allowed the SHA-1 Trusted Root Certificate Authority to expire as of May 9, 2021. Windows 8 and above users won't be affected however, .NET developing will be for Windows 7 and above. Norton is already aware of it Which brings to mind WHY event 3033 CONTINUES to be an issue.
Because software publishing certificates was deprecated on 15th April 2021, Norton will switch code signing to SHA 2 certificates.
I was again dissapointed in the current update to my Norton Security product, to version 22.21.3.48, as the Event 3033 for Code integirty is STILL NOT FIXED:
"Code Integrity determined that a process (\Device\HarddiskVolume1\Windows\System32\SIHClient.exe) attempted to load \Device\HarddiskVolume1\Program Files\Norton Security\Engine\22.21.3.48\symamsi.dll that did not meet the Windows signing level requirements."
I am sick and tired of this error "littering" my Event log, so at the next subscription point (157 days), the product will be removed if this is not resolved.
@SoulAsylum thanks for that very useful information. I have now seen those history log expansions, and i see they are all INFO and not a problem report. Mine seem to be related mostly to Web Protection, probably because I have the Norton Safe Web extension running in my Firefox browser, although I DO see many other caches being referenced in some of those files too. I checked some with Wordpad to do a crude "lookup" of what is in there. The article on the 0x80004005 error is rather old and out of context here, as it can occur in MANY places in Windows 10, notably from Feature Update failures, and other complex update failures.See this very useful site for quick error-code lookups: https://www.hresult.info/FACILITY_NULL/0x80004005
As you can see it is that horrible E_FAIL (DDERR_GENERIC) "There is an undefined error condition". About as useful as a Chocolate teapot! IMHO - this is just a catch-all for an unexpected NULL return or other errors in whatever scripting, .NET or other WIN32 API is active, due to lazy coding techniques and lack of defensive code. The HRESULT site is very useful to find the "ERROR GROUP", in this case the "FACILITY_NULL" set.
I will continue to monitor my systems, having gained this useful info from you, to see if anything "odd" turns up to do with certs.
If you open an entry in your Norton history under "Norton error reporting", look at the bottom right side of the dialog for "More Options" in blue letters, and click it. The advanced details should present a new dialog as shown in my screenshot.
Error code 0x800704DC and error code 0x80004005 are both present within the current entries in my Norton history. Datastor is throwing code 0x800704DC which represents improper user authentication in Windows or file corruption. In my case with this machine NEITHER is the issue. Running DISM reports no issues with my installation and health of the install.
Error code 0x80004005 as shown in my screenshot above, shows the following as stated in this linked article:
Error code 0x80004005
This problem may occur if a file that the Windows Product Activation (WPA) requires is damaged or missing. This behavior occurs if one or both of the following conditions are true:
A third-party backup utility or an antivirus program interferes with the installation of Windows XP.
A file that WPA requires is manually modified.
Both error codes are co-related. I DO have boot-time scanning set to aggessive as well. Fast startup is disabled on the system and Norton backup is also disabled. These two codes seem to be pointing at both. I'll set boot time scanning to normal and reboot, check for error reporting throwing another entry.
@SoulAsylum - that is an interesting post. I don't have that "Security History - Advanced Details" section. I only have NIS (Now just called Norton Security), so I guess that is part of your N360 DeLuxe"? Wha exactly is it finding "wrong" with those objects? I see one file is an "etl" file (Event Trace Log) format, so is that what it does not like, or is it part of its reporting "system" of files during the action?
Here is another small note of interest that I have recently uncovered. Boat loads of "Cert Analysis" submissions for the same event, same component name, same hashcode. Below is an example of just one of the entries.
The perspective I get is somehow, Norton has the idea there is a hidden certificate which isn't shared with AMSI providers / vendors that is the cause of this event being thrown by Windows and logged. The facts are, its the improperly NORTON signed certificate that causes the issue with event ID 3033 due to code signing validation. I've had Windows on one machine, throw event 3033 several times in rapid succession which caused an instant powering OFF. Just a simple instant click and was powered off to protect the OS as Windows is designed. Norton doesn't seem to believe that is possible. System event logs don't lie, they record what is sent them.
As far as I am concerned, if the powering down events continue even randomly, Norton will have to be removed from this machine at least. No two devices will behave in the same way and that would be the reasoning behind that. Damage to this machine would be seriously a bad thing as well although I backup once a week. Still not a good scenario to lose data due to an issue where the blame game takes place rather than fixing the issue. Stay healthy and safe.
FYI Nothing directly or indirectly from Norton. However, there WAS a patch level jump to version 22.21.2.50 (from 22.21.1.150). IMagine my dissappoinment after downloading a 130MB patch update, and an install, only to see the SAME boring old EVENT 3033 appearing still: "Code Integrity determined that a process (\Device\HarddiskVolume1\Windows\System32\svchost.exe) attempted to load \Device\HarddiskVolume1\Program Files\Norton Security\Engine\22.21.2.50\symamsi.dll that did not meet the Windows signing level requirements."
Just to remind Norton, they are on a clock: after 196 days, if this is NOT fixed, then I will NOT be renewing my subscription.
@SoulAsylum - thanks for the latest feedback. Hopefully, if there are others (and maybe some corporate customers) reporting this and other related issues, then maybe the extra pressure will start to get some action, and maybe even a fix to their product!!
Update: This is not only an expired certificate issue on the part of Norton it is also a code integrity issue. I have a response from my contact and am not at liberty to provide any of it here in open forums. Someone Norton SHOULD entertain getting involved with the thread here and others, that are also related so that customers can get THEIR response directly from Norton.
@SoulAsylum - thanks for pushing up to Norton. It is good to know (for others), that Insider builds are not supported officially by Norton. I have NEVER used the Insider releases, as I do NOT have a spare system to risk my daily needs.It is bad enough risking ANY update with ANY vendor these days, and as far as Insider Beta stuff, I just do not have time to "Beta Test" stuff for free. My mantra is "There is no such thing as perfect software"!
One thing to note, developer builds on Windows 10 are not officially supported by Norton, although Norton products may actually run on those builds. I used Norton on W10 as an insider as far back as before the original RTM release without issues. Hoping for a solid answer or Norton intervention into the thread at some point.
Edited: The laziness of incorrect coding also begins here: https://docs.microsoft.com/en-us/windows/win32/api/unknwn/nn-unknwn-iunknown
SA
