July 22, 2021 at 9:32 am
Hi All,
I am hoping you may be able to shed some light on an issue which has been troubling my company for some time.
We have a server running SQL and SSRS which seems to randomly and intermittently suffer from SSRS outages.
The problem presents itself in two ways:
The underlying compression routine could not be loaded correctly.
The type initializer for 'NativeZLibDLLStub' threw an exception
Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))"
The solution in both cases is to restart the SSRS service, but this has to be done when logged in as the service account which is also running the service - If you log in as any other user and restart the service it doesn't work.
I would be really grateful if anyone could shed some light on the issue.
Kind Regards,
John
July 22, 2021 at 3:02 pm
Step 1 - check the logs.
I would probably reach out to the server admins (and check the logs) to determine why starting the service as a user other than the service doesn't allow it to start as well. There should be no reason why a server admin shouldn't be allowed to start a service.
Getting a random "access is denied" error though sounds like something is happening on the server that shouldn't be such as the antivirus locking a file used by SSRS, or the SSRS account is getting locked out, or possibly corruption of some sort (disk or memory for example).
But, start by checking the logs. My FIRST step to correcting the issue (after reviewing the logs) would be to clone the server so I can restart things and test stuff without impacting production. Next, I'd log in as a server admin, try to restart the SSRS and wait for it to fail. Then I'd check the logs, correct the issue, and try to restart SSRS again. Repeat until SSRS starts successfully.
Next I'd check the AD (you are using AD, right?) logs to see if the service account had been locked out recently and if so, from where. If that came back empty, I'd be running a memory check tool on the server as well as chkdsk on the drive.
Might not hurt to check that you are fully patched too. Could be a known bug that is fixed in a future patch.
But step 1 - check the logs. Check all of the logs that make sense. Windows, SSRS, AD, etc.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply