Forum Discussion
Power Query "Could not load file or assembly System.Memory, Version=4.0.1.2"
Hoping someone has seen this one. A workbook that refreshes a Power Query fails with:
"Could not load file or assembly 'System.Memory, Version=4.0.1.2, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified."
The failure is inside the Mashup evaluation engine — the call stack ends in the data-privacy firewall / buffered evaluator and an OLEDB result-writer (Microsoft.OleDb.Column.TypeHandler → ExcelTableWriter).
When it happens: the query opens the workbook itself from disk (Excel.Workbook(File.Contents(...))) and combines that with in-workbook data, so it goes down the data-privacy firewall / buffered evaluation path. Simple single-source queries on the same machine refresh fine.
Environment (this is the strange part):
FAILS: two Windows 11 PCs, on BOTH 64-bit and 32-bit Office.
WORKS: one Windows 10 PC.
All three are on the IDENTICAL build: Microsoft 365, Version 2606, Build 16.0.20131.20112.
Same file and same source data on all three.
Already tried, no fix:
Office Quick Repair and full Online Repair
Full uninstall/reinstall of Office
Repair/reinstall of .NET Framework 4.8
Clearing the Power Query cache
Disabling all add-ins / empty XLSTART
"Ignore Privacy Levels" (global + workbook)
Switching Office bitness (64→32) — still fails on Win11
IT captured a Fusion assembly binding log and tried fixes based on it — no success
Clues:
It WORKS when Excel is run as Administrator, and in Safe Mode.
It FAILS in a normal standard-user session.
There is no System.Memory in the GAC on the failing machines.
Intermittent — sometimes works briefly after a reinstall, then fails again.
The "works as admin / Safe Mode, fails as standard user" pattern makes me suspect the assembly load is being blocked or mis-resolved for the standard-user token on Windows 11 specifically — and possibly it's a dependency (System.Runtime.CompilerServices.Unsafe or System.Numerics.Vectors) rather than System.Memory itself.
Same error, unresolved, reported here: https://learn.microsoft.com/en-us/answers/questions/5937472/how-to-fix-power-query-error-system-memory-the-sys
Questions:
Has anyone found the root cause or a reliable fix?
Is this a known issue tied to a recent Windows 11 build, an EDR/security agent, or a specific .NET assembly on Win11?
Any way to force Power Query to resolve System.Memory (and its dependencies) correctly for a standard user?
Thanks in advance — happy to share the Fusion binding log or more detail.
Hi jake_duct
Based on the pattern you described, this looks much more like a Windows 11 / standard-user / security-policy / assembly-loading issue than a workbook or Power Query design problem.Why that’s the best fit:
- Works as Administrator
- Works in Safe Mode
- Fails only in a normal standard-user session
- Only on Windows 11
- Error is a missing .NET assembly during Mashup evaluation: System.Memory, Version=4.0.1.2
That usually points to one of these:
- EDR / antivirus / application control interference
- Controlled Folder Access
- AppLocker / WDAC / policy restrictions
- Per-user cache or temp-folder permissions
- A Windows 11-specific compatibility regression
- A broken user profile or user-scoped Office/Mashup cache
What to try
1) Test with a brand-new Windows user profile
Create a fresh standard user and test the workbook there.
- If it works: the issue is likely profile-specific
- If it fails: the issue is more likely machine policy / security stack / OS build
2) Ask IT to check security controls
Since Safe Mode works, I’d focus first on:
- EDR / antivirus exclusions
- Controlled Folder Access
- AppLocker
- WDAC
- ASR rules
- restrictions on Office child processes or embedded runtime loads
Useful exclusions to test:
- EXCEL.EXE
- Office / Click-to-Run paths
- %LOCALAPPDATA%
- %TEMP%
- Power Query / Mashup cache locations
3) Compare Win10 vs Win11 policy state
Since the same build works on Windows 10, compare:
- cumulative updates
- Defender policies
- MDM / GPO settings
- EDR agent version and policy
- local security baseline differences
4) Clear user-side Office/Mashup cache
You already tried Office repair, which is good. But if the issue is profile-scoped, user-side cache cleanup may still matter.
5) Try a different Win11 patch level
If this started after a Windows update, test:
- a rollback, or
- a newer cumulative update
That can confirm whether this is a Windows 11 regression.
About System.Memory
System.Memory is often the symptom, not the real cause. Power Query is likely failing while loading something in the embedded runtime path, and the assembly load error is what bubbles up.
So the fix is usually not “manually install System.Memory” or add it to the GAC. The better fix is to remove whatever is blocking the Mashup engine from loading its dependencies under a standard user token.
Practical workaround
Until IT isolates it:
- run Excel elevated as a temporary workaround
- or use the Windows 10 machine for that workbook
5 Replies
Hi jake_duct
Based on the pattern you described, this looks much more like a Windows 11 / standard-user / security-policy / assembly-loading issue than a workbook or Power Query design problem.Why that’s the best fit:
- Works as Administrator
- Works in Safe Mode
- Fails only in a normal standard-user session
- Only on Windows 11
- Error is a missing .NET assembly during Mashup evaluation: System.Memory, Version=4.0.1.2
That usually points to one of these:
- EDR / antivirus / application control interference
- Controlled Folder Access
- AppLocker / WDAC / policy restrictions
- Per-user cache or temp-folder permissions
- A Windows 11-specific compatibility regression
- A broken user profile or user-scoped Office/Mashup cache
What to try
1) Test with a brand-new Windows user profile
Create a fresh standard user and test the workbook there.
- If it works: the issue is likely profile-specific
- If it fails: the issue is more likely machine policy / security stack / OS build
2) Ask IT to check security controls
Since Safe Mode works, I’d focus first on:
- EDR / antivirus exclusions
- Controlled Folder Access
- AppLocker
- WDAC
- ASR rules
- restrictions on Office child processes or embedded runtime loads
Useful exclusions to test:
- EXCEL.EXE
- Office / Click-to-Run paths
- %LOCALAPPDATA%
- %TEMP%
- Power Query / Mashup cache locations
3) Compare Win10 vs Win11 policy state
Since the same build works on Windows 10, compare:
- cumulative updates
- Defender policies
- MDM / GPO settings
- EDR agent version and policy
- local security baseline differences
4) Clear user-side Office/Mashup cache
You already tried Office repair, which is good. But if the issue is profile-scoped, user-side cache cleanup may still matter.
5) Try a different Win11 patch level
If this started after a Windows update, test:
- a rollback, or
- a newer cumulative update
That can confirm whether this is a Windows 11 regression.
About System.Memory
System.Memory is often the symptom, not the real cause. Power Query is likely failing while loading something in the embedded runtime path, and the assembly load error is what bubbles up.
So the fix is usually not “manually install System.Memory” or add it to the GAC. The better fix is to remove whatever is blocking the Mashup engine from loading its dependencies under a standard user token.
Practical workaround
Until IT isolates it:
- run Excel elevated as a temporary workaround
- or use the Windows 10 machine for that workbook
Hi jake_duct
We would like to inquire whether have you got the chance to check the solutions provided by powerbidev123 in commiunity to resolve the issue. We hope the information provided helps to clear the query. Should you have any further queries, kindly feel free to contact the Microsoft Fabric community.Hi jake_duct
We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. And, if you have any further query do let us know.
Thank you.We are also experiencing this issue, has anyone found a fix yet?
Safe mode/elevated does not work on our instance
Hi jake_duct
As mentioned by powerbidev123 Have you reviewed and confirmed the workarounds above?
