We’ve identified an issue this morning affecting import/export actions in IFS, such as downloading document attachments from purchase orders. When users attempt to save a file to their local machine, the IFS client crashes and closes. We’ve tested this across multiple user devices, and the behaviour is consistent.
Everything was functioning normally before the weekend, but as of this morning the feature is failing entirely in both our production and development environments.
As an additional check, I tested the same actions directly on the server/VM hosting our middleware instance, and import/export works correctly there. This makes me suspect the issue may be related to something on the local Windows machines, possibly a recent update.
Our application is accessed through an App Gateway, but this has been in place for some time without any issues, so it seems unlikely to be the cause.
Has anyone else seen this?
Best answer by TmRyk
We’ve identified the cause of the crash and a temporary workaround.
IFS EE ships its own copy of msvcp140.dll inside the 2.0 folder. In our environment that DLL is version 14.16.27033, which is several years old. Windows 25H1/25H2 includes a much newer Visual C++ runtime (our machines are running 14.44.35211). When IFS opens a File Explorer dialog, Windows loads the older DLL from the 2.0 folder instead of the system version. The version mismatch causes IFS EE to crash immediately.
If we delete the IFS‑bundled msvcp140.dll, Windows falls back to the system runtime and the crash disappears. Importing and exporting files then works normally.
The limitation is that if a user deletes their 2.0 folder or reinstalls IFS EE, the old DLL is downloaded again and the issue returns.
We’re currently testing an Intune policy to automatically remove the outdated DLL so IFS EE consistently uses the Windows runtime instead.
We’ll also highlight this with IFS to ensure a future patch will resolve it.
We’ve identified the cause of the crash and a temporary workaround.
IFS EE ships its own copy of msvcp140.dll inside the 2.0 folder. In our environment that DLL is version 14.16.27033, which is several years old. Windows 25H1/25H2 includes a much newer Visual C++ runtime (our machines are running 14.44.35211). When IFS opens a File Explorer dialog, Windows loads the older DLL from the 2.0 folder instead of the system version. The version mismatch causes IFS EE to crash immediately.
If we delete the IFS‑bundled msvcp140.dll, Windows falls back to the system runtime and the crash disappears. Importing and exporting files then works normally.
The limitation is that if a user deletes their 2.0 folder or reinstalls IFS EE, the old DLL is downloaded again and the issue returns.
We’re currently testing an Intune policy to automatically remove the outdated DLL so IFS EE consistently uses the Windows runtime instead.
We’ll also highlight this with IFS to ensure a future patch will resolve it.
