Windows 11 — Are These Errors Caused by the Operating System or by Third-Party Software?

Based on the observations, the Python exceptions and editing failures are characteristic of application, library, or development-tool behavior; the only unresolved item is where the reported file writes actually went, and none of the evidence positively identifies a Windows operating-system failure.

Symptom-by-symptom classification

These incidents should remain separate unless timestamps, process identities, paths, or a shared lower-level error connect them.

Could permissions produce a “successful” but invisible write?

Possibly, but only under specific conditions.

A straightforward NTFS permission denial normally produces a failure such as Win32 error 5 or HRESULT 0x80070005 (E_ACCESSDENIED), rather than a genuine successful write.^3^

Windows can, however, redirect writes:

• A legacy, non-elevated 32-bit application without an appropriate requested-execution-level manifest can have writes to protected locations redirected to a per-user VirtualStore. This does not apply to elevated applications, non-elevated 64-bit applications, or applications whose manifest specifies an execution level.^4^
• A packaged desktop/MSIX application can receive a private, per-user, per-app view of certain files. Writes may therefore be visible to that application but not at the physical path inspected by another process.^5^

Those mechanisms are relevant only if the automated tool meets the corresponding legacy-32-bit or packaged-app condition. Otherwise, different working directories, repositories, profiles, containers, or inaccurate success reporting are at least as plausible. “Elevated versus restricted” alone does not prove redirection.

Significance of the responsive system and empty event window

The responsive computer, absence of a blue screen/restart, and lack of a correlated System or Application error materially reduce the likelihood of a kernel-level crash, unexpected shutdown, or recorded application crash.

They do not prove Windows was fault-free: some application exceptions are caught by their runtime and never become Windows Error Reporting events, and abrupt power loss or a hard hang can sometimes prevent complete logging. Microsoft documents Event ID 41 as evidence that Windows subsequently detected an unclean shutdown, while noting that the event may be absent or contain zero codes when the system could not write diagnostic information.^6^

Here, however, there was no observed shutdown, restart, or hard hang. That exception to logging therefore has no affirmative support.

Events and codes that would discriminate the causes

The following would be meaningful if temporally correlated with a recurrence:

• Application log, Event ID 1000 — Application Error: actual process crash, including the faulting executable/module and exception code.
• Application log, Event ID 1001 — Windows Error Reporting: associated crash or hang report. Repeated IDs 1000 and 1001 indicate application-crashing behavior, whether the executable is Microsoft or third-party.^7^
• Relevant exception codes include:
  • 0xC0000022 — STATUS_ACCESS_DENIED
  • 0xC0000005 — access violation
  • 0xC0000374 — heap corruption
    A Microsoft DLL such as ntdll.dll, kernel32.dll, or kernelbase.dll appearing as the faulting module does not alone prove an OS defect; these modules can be where corruption caused elsewhere becomes visible.^7^
• System log, Kernel-Power Event ID 41: unclean restart.
• System log, WER-SystemErrorReporting Event ID 1001: reboot from a bugcheck, normally with a bugcheck code and dump location.
• Event ID 6008: prior shutdown was unexpected. Reboot analysis may also correlate IDs 19, 41, 1001, 1074, and 7045.^8^
• Microsoft-Windows-WHEA-Logger events: hardware errors reported through Windows Hardware Error Architecture.^9^
• Bugcheck 0x24 — NTFS_FILE_SYSTEM: positive evidence of a serious NTFS/ntfs.sys path failure, potentially involving filesystem corruption, storage media, or storage drivers.^10^
• Security Event ID 4663: records access to an audited filesystem object, but only when object-access auditing and the applicable file/folder audit rule were enabled. Its absence without prior auditing proves nothing.^11^

Conclusion

There is no positive evidence in the listed symptoms of a Windows malfunction. Items 1–4 are directly consistent with application assertions, expected test exceptions, platform-dependent library behavior, and automated-editing failures. Items 5–6 remain undetermined because the process identity, token, package/container status, working directory, target path, and native write result were not established.

The absence of correlated Windows events is supporting negative evidence—not absolute proof—but, together with continued responsiveness and no restart or bugcheck, it makes an operating-system-level failure substantially less likely than independent application/tool issues.

References

1. socket — Low-level networking interface — Python 3.11.17 documentation
2. Platform Support — Python 3.15.2 documentation
3. Troubleshoot Windows Update error 0x80070005
4. UAC Architecture
5. Understanding how packaged desktop apps run on Windows
6. Advanced troubleshooting for Event ID 41: "The system has rebooted without cleanly shutting down first"
7. The application or service crashing behavior troubleshooting guidance
8. Troubleshoot unexpected reboots using system event logs
9. Querying the System Event Log for Hardware Error Events
10. Bug Check 0x24: NTFS_FILE_SYSTEM
11. Audit Visual C++ Runtime version usage