Dtrace throws a SharedMemorySink error when trying to monitor or write a log file
book
Article ID: 100034047
calendar_today
Updated On:
Description
Error Message
Cause
Parsed differently, this status code is another representation of the commonly encountered "Access denied" hex code in Windows, 0x80070005. Therefore, this is a permissions issue, but the issue resides in the Vault Service Account's (VSA's) permission to an active block of memory used to host the actions of dtrace.exe.
The situations and/or conditions that can cause this vary wildly; and therefore no specific cause can be cited. However, any rules that dictate access to certain system actions and memory use are controlled by registry settings for users, which are typically pushed out with Group Policy Objects (GPO's).
Resolution
The following is a temporary solution, meant to prove/disprove the involvement of a GPO as the culprit.
- Ensure all dtrace threads are stopped fully
- Exclude the EV Server AND the VSA from all GPO's
- Either force a Group Policy update in cmd (gpupdate /force) and restart all EV services, or, reboot the server.
Note: The use of GPO's that target the EV Server or the VSA is supported, and this article is in no way meant to imply they should not be used in an EV environment. The purpose of this solution is meant to illustrate that GPO's can cause memory access problems for various reasons, and should be investigated or re-configured if the temporary exclusion fixes the dtrace problem.
Issue/Introduction
When attempting to run dtrace, upon either executing the "mon" command or the "log" command, an error is thrown similar to this:
Err: {SharedMemorySink::InitialiseMemoryObjs:#217}
Status: 80.070.005
Depending on the version of Enterprise Vault (EV), the code on the "Status" line might be comma delimited, rather than with periods, like this: 80,070,005.
Was this article helpful?
thumb_up
Yes
thumb_down
No