Forum Discussion

Dennis_van_Turn's avatar
12 years ago
Solved

Some process recalling placeholders?

From time to time I see messages in our monitor app about EV not being able to recall placeholders. Usually its not a couple but the whole archived content of a folder.

 

Had a look at this article and proposed a change to exclude TrendMicro AV.

http://www.symantec.com/business/support/index?page=content&id=TECH51039

Since this article hints on how to find what process requested the recall, the request for change as was denied with the comment to do the DTrace part first. I've been doing some tests but not sure how to extract the process from the log.

Any ideas on how to find this info?

 

5 Replies

  • Hi Dennis,

    If you collect a dtrace in the file server and add the EvPlaceholderService, you can take a look at the dtrace and you will see what process is recalling the placeholders. For instance, this is an excerpt from my lab:

    (EvPlaceholderService) <19766> EV:L RequestArchivedFile::RequestArchivedFile Caller SID is S-X-X-XX-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-XXXX
    (EvPlaceholderService) <19766> EV:M WorkItem::GetExeName: Trying to get the .exe name for pid: ####
    (EvPlaceholderService) <19766> EV:M WorkItem::GetExeNameUsingPHHelper: entry - PID: ####
    ...
    (EvPlaceholderService) <19766> EV:M WorkItem::GetExeNameUsingPHHelper: exit - PID: ####, exe name: <process.exe>

    In your file server, you will see something like the entries above. In <process.exe> you will find what process is recalling the PHs. This is for Windows file server. If you have another file server, such as a NetApp filer, the placeholder service should be running in the EV server.

    I hope this helps.

  • My RDP Session with the dtrace was reset before the rogue process started leaving me with no logging on what process requested the placeholder to be recalled.

    I have lots of Event ID 20491 on the fileserver: Error downloading file: ... Error There is not enough space on the disk. (0x80070070). Which is to be expected since there isn't enough space for all archived data.

    Narrowed it down to something running on Sunday.

    Guess I have to wait till next weekend to learn more about what's causing it.