---
title: "How do I Confirm the Block Source?"
url: "https://dm0bkdes5q7a2ls.productfruits.help/en/article/how-do-i-confirm-the-block-source"
language: "en"
last_updated: "2026-06-16T15:45:13.740Z"
---

# 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.
3.  -   **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:
5.  -   **`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.