Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.
Archiving and eDiscovery Community Blog

How to find the process recalling a placeholder

Created: 23 Sep 2013 • Updated: 29 May 2014
Rob.Wilcox's picture
0 0 Votes
Login to vote
Sometimes in order to figure out what is happening in Enterprise Vault FSA it might be necessary to determine which process is recalling items. What I mean is that you might see some sort of mass recall issue, where lots and lots of items are constantly being turned back from placeholders to full-fat items, and, you want to know why!
The way to determine what is recalling the placeholders is to perform a DTrace of the EVPlaceholderService, perform a recall (or leave things running for a while if something is mass-recalling items) and then review the DTrace. In detail then we would:
1. Login to the file server that is hosting the Enterprise Vault placeholder service.
2. Open an elevated command prompt
3. Go to the EV Program Files folder
4. Launch DTrace (by typing dtrace, and then return)
5. Do: set EVPlaceholderService V
6. Do: log c:\temp\who-is-it.log
7. Maybe, depending on how busy your file server is, do the command MON, just for a little while so you can see things working.
8. On a desktop/laptop machine, open Windows Explorer, and browse to the share (or one of the shares) that is on the file server that was just configured for tracing.
9. Open 1-2 placeholders of different file types
10. Check that MON is showing something.
11. Review the trace.
In the trace you should see things like this:
210  10:58:50.568 [3,844] (EvPlaceholderService) <2848> EV:M Filter message event signaled [WAIT_OBJECT_0 + 1]

211  10:58:50.568 [3,844] (EvPlaceholderService) <2848> EV:M [EvRequestArchivedFile] Queueing placeholder request for file: C:\source\EV 2007 ReadMeFirst_EN.htm

212  10:58:50.584 [3,844] (EvPlaceholderService) <2848> EV:L {RequestArchivedFile::RequestArchivedFile} (Entry)

213  10:58:50.584 [3,844] (EvPlaceholderService) <2848> EV:L RequestArchivedFile::RequestArchivedFile Caller SID is S-1-5-21-2561182712-3591106754-569776174-500

214  10:58:50.584 [3,844] (EvPlaceholderService) <2848> EV:M WorkItem::GetExeName: Trying to get the .exe name for pid: 3888

215  10:58:50.584 [3,844] (EvPlaceholderService) <2848> EV:M WorkItem::GetExeNameUsingPHHelper: entry - PID:3888

216  10:58:50.600 [3,844] (EvPlaceholderService) <2848> EV:M WorkItem::GetExeNameUsingPHHelper: exit - PID:3888, exe name:iexplore.exe

217  10:58:50.615 [3,844] (EvPlaceholderService) <2848> EV:M WorkItem::GetExeName: The .exe name for for pid: 3888 is iexplore.exe

218  10:58:50.615 [3,844] (EvPlaceholderService) <2848> EV:L {RequestArchivedFile::RequestArchivedFile} (Exit) Status: [Success]

219  10:58:50.615 [3,844] (EvPlaceholderService) <2848> EV:L {CQueue::EnQueue} (Entry)
That can be helpful to see what is recalling files, though of course you might have to leave the trace running for some time in order to see the mass-recall effects.  You might also see that the PID can't be resolved to a process.  In my testing this was always the case when the recall was happening from a different machine, rather than the local file server...  your testing results may differ!