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

User-added image

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.