How do I Confirm the Block Source?

To confirm the exact source of an "Access Denied" block, you must use a process of elimination to distinguish between NTFS Permissions, Share Permissions, and Security Software (AV/EDR).

Follow these 4 steps to identify the cause of the "Access Denied" error:

Step 1: Check the Spirion Agent Log (The Symptom)

Open the local Agent log at C:\ProgramData\Identity Finder\Logs\Agent_YYYY-MM-DD.log and search for the file path that failed.

  • If you see System Error: 5: This is a generic "Access Denied." It could be permissions OR an antivirus block.
  • If you see System Error: 32: This is a File Lock. The file is open in another program (like Excel or Outlook). This is not a block; it's a sharing violation.
  • If you see The handle is invalid: This often points to a network disconnection or a deep-level AV interception.

Step 2: The "Manual Mimic" Test (Rule out Permissions)

The most common mistake is testing with your own account. You must test as the Service Account.

  1. Log into the machine as the Spirion Service Account.
  2. Try to manually open the file, rename it, and move it.
    • If you CANNOT do this manually: The issue is NTFS or Share Permissions. (Check the "Effective Access" tab in file properties).
    • If you CAN do this manually: The permissions are correct. The block is being triggered by the behavior of the spirion.exe process specifically. Proceed to Step 3.

Step 3: Check Event Viewer (The Smoking Gun)

Look for the specific Event IDs we discussed to see who "claimed" the block:

  • Defender Block: Go to Applications and Services Logs > Microsoft > Windows > Windows Defender > Operational.
    • Look for Event 1117 or 1123.
    • If found, Defender is the source.
  • OS/Permission Block: Go to Windows Logs > Security. Look for Event 4663 with a "Failure" status. If the "Subject" is the service account and the "Process" is spirion.exe, the Windows OS blocked it based on an ACL.
  • EDR Block: Check your EDR console (CrowdStrike, SentinelOne, etc.). If the EDR killed the spirion.exe process, it will log a "Prevention" event.

Step 4: Use Process Monitor (The "Ultimate" Confirmation)

If you still aren't sure, use the free Microsoft tool Process Monitor (ProcMon).

  1. Run Process Monitor - ProcMon - on the Agent machine.
  2. Set a filter for Process Name is spirion.exe.
  3. Start the Spirion scan.
  4. Look for the Result column in ProcMon:
    • ACCESS DENIED: Look at the "Detail" column. If it mentions a "Filter Driver," a security tool (AV) intercepted the request.
    • FILE LOCKED WITH ONLY READERS: Another app has the file open.
    • CANT_ACCESS: Usually indicates the network share path is unreachable.


Summary: How to tell the difference

If the source is...

You will see...

NTFS Permissions

Manual test fails; Event 4663 (Failure) in Security Log.

Share Permissions

Manual test works on the server locally, but fails over the network (UNC).

Windows Defender

Event 1117 or 1123 in the Defender Operational log.

EDR (CrowdStrike/S1)

spirion.exe process disappears from Task Manager; "Prevention" in EDR console.

File Lock

System Error: 32 in Spirion logs; "Sharing Violation" in ProcMon.

Conclusion

If the manual test as the service account works, but the scan fails, the source is almost certainly your AV/EDR flagging the spirion.exe process behavior.