Code Integrity Error Event ID 3033, is there a solution being worked on?
I did see this in another thread already created and the reason I am starting a new thread is because it said it was answered. There was no real solution in that thread or a fix.
I am receiving this Code Integrity error Event ID 3033 with Information Event ID 3089 as well. It pops up in the log every minute.
Event ID 3033: Code Integrity determined that a process (\Device\HarddiskVolume5\Windows\System32\SecurityHealthService.exe) attempted to load \Device\HarddiskVolume5\Program Files\Bitdefender\Bitdefender Security\bdamsi\dlls_267059357120000000\antimalware_provider64.dll that did not meet the Windows signing level requirements.
Event ID 3089: Signature information for another event. Match using the Correlation Id.
I noticed, in the other thread, after \Device\HarddiskVolumeX\Windows\System32
XXXXXX.exe is different for each user with this problem.
Also wondering if this issue is currently being worked on.
Running Windows 11 Pro Ver. 24H2
Everything is up to date including BIOS.
TY
Answers
-
Hello,
Based on my findings, the file is valid. The only reason why this error occurs is that Microsoft doesn't have a standard method for signing 3rd party libraries (the amsi library, in our case) to load into protected light processes.
Also, there is no way to tell the operating system not to try to load us into ppl processes.Can you share the other thread you were refering to? 'Answered' doesn't necessarily mean that the discussion was concluded with a resolution.
Regards
Premium Security & Bitdefender Endpoint Security Tools user
0 -
Can you share the other thread you were refering to?
Thank you for your reply.
Here's the link to the other thread.
As I understand it from the error the process is trying to load, but windows is denying it from doing so. From the image I inserted I am not sure under what process it would be loaded as. Maybe you have some clarity on that.
Again, thank you.
0 -
The Windows Security Health Service, which runs in protected mode, attempts to load our DLL due to a dependency chain. In reality, it’s only being initialized because of that chain. According to Microsoft documentation, such DLLs are not permitted to load into PPL processes, so it inevitably fails.
The error about the DLL not meeting the required signing level refers to Microsoft’s PPL requirements, while the AMSI DLL itself is not intended for this usage. The main issue is that the Windows PPL service is attempting to load antimalware_provider.dll because of the dependency chain.
2