Microsoft's published retirement date for InfoPath was 14 July 2026. Stated here as context for why these errors are becoming more common — not as a countdown to anything.

If InfoPath has stopped opening a form it used to open fine, the first useful thing to know is that the error text matters. People search for all four of these interchangeably, but they point at different failures, and two of them have fixes that take about ninety seconds.

The four messages, and what each one is actually telling you

1. "InfoPath cannot open a new form."

This is the general one — InfoPath tried to build a form to show you and could not. It very rarely means your record is damaged. In practice it usually means the template could not be fetched or read: a corrupted cached copy, a template location that no longer resolves, or a permissions problem on the way to it. Start with the cache fix below.

2. "The form cannot be opened. To fix this problem, contact the form designer."

This one is more specific: InfoPath found the template but could not use it. Typical causes are a feature the installed InfoPath build cannot run, managed code (a code-behind assembly) the machine will not load, or a data connection the template tries to open on startup that no longer answers. Note that all three are properties of the template's behaviour — not of the field values stored in your record.

3. "Access is denied."

Read this one literally. Something in the chain is a permissions problem: the SharePoint library, the network share, the local cache folder, or the account you are signed into. It is the least mysterious of the four and often the quickest to resolve — but it is also the one most likely to reappear later, when a site is decommissioned or a group membership changes.

4. "InfoPath cannot open the following form … The file is not a valid XML document."

Here the file itself is being rejected by the XML parser. Sometimes that is genuine damage. Very often it is something more boring: the file was truncated by a copy that did not finish, it was saved with a stray byte-order mark, or it is not the file type its extension claims. Open it in a plain text editor before you conclude anything — an InfoPath record is human-readable XML and you will usually be able to see immediately whether the content is there.

Worth knowing before you troubleshoot anything. A filled-in InfoPath record is a plain .xml file, and an .xsn template is a Microsoft Cabinet (CAB) archive containing open XML parts — a manifest, an XSD schema, and XSL view transforms. Neither is encrypted and neither is a proprietary binary. So even when InfoPath refuses to open something, your field values are almost always still sitting there in readable form. That single fact takes most of the panic out of these errors.

The free fixes, in the order worth trying them

Step 1 — Clear the InfoPath form-template cache

When InfoPath opens a form from SharePoint or a share, it downloads the template and keeps a local copy. If that copy goes stale or gets damaged, InfoPath will keep failing on it rather than fetching a fresh one. Microsoft documents a command-line switch for exactly this: from the Run box, enter

  • infopath /cache clearall

If you would rather do it by hand — and this is what a Microsoft Q&A moderator suggested to someone hitting the "cannot open a new form" and "access is denied" pair — back up and then empty the contents of both of these folders:

  • C:\Users\<username>\AppData\Local\Microsoft\InfoPath
  • C:\Users\<username>\AppData\Roaming\Microsoft\InfoPath

The cached templates live under ...\AppData\Local\Microsoft\InfoPath\FormCache2. Copy the folders somewhere first, so the step is reversible. This does not touch your records — the cache holds downloaded templates, not your data.

Step 2 — Check where the record thinks its template lives

Every filled-in InfoPath .xml carries a processing instruction at the top of the file pointing at the template that created it — an href to an .xsn, plus a solution name and version. Open the .xml in Notepad or any text editor and look at the first two or three lines. If that href points at a SharePoint site that has been retired, a server that no longer exists, or a mapped drive letter this machine does not have, you have found your cause. There is a free fix for that, and it has its own guide.

Step 3 — Rule out the obvious permission cases

Confirm you can actually reach the library or share as the signed-in account, in a browser or in Explorer, before blaming InfoPath. If the template sits on a site you no longer have rights to, InfoPath will report a form problem rather than a permissions one, which sends a lot of people down the wrong path.

Step 4 — Try a repair, then a different machine

An Office repair is worth one attempt. After that, if a colleague's machine opens the same file, the problem is local and you have a working route for today. Be honest with yourself about what that route is worth, though: it depends on one particular installation continuing to exist.

When fixing InfoPath is the wrong goal

There is a point where the sensible move changes. If any of these are true, the aim should stop being "make InfoPath open this" and become "get the data out into something anything can read":

  • You need the records for retention, audit, a subject-access request, or a legal hold — where the requirement is on the data, not on the original application.
  • The template the records point at is genuinely gone, and nobody can produce it.
  • You have hundreds or thousands of records and one working machine standing between you and all of them.
  • Nobody left in the organisation can support InfoPath, and the estate has to survive that.

InfoPath reached Microsoft's published end of support on 14 July 2026. Nothing deletes your files on a date, but every quarter after it makes "keep the old install alive" a weaker plan.

Getting the data out — your options, honestly, free ones first

1. Export from a working InfoPath install (free)

If you have a machine where InfoPath still runs, use it while you have it. File → Export To gives you PDF or XPS per form, and you can copy field values out by hand. Genuinely free, genuinely fine for a handful of records, and worth doing today rather than next quarter. It does not scale, and it depends on the install you are trying to stop depending on.

2. Read the XML yourself (free, technical)

A filled-in record is plain XML. Open it in a text editor and the values are right there. With a little scripting you can pull the same values out of a whole folder — a few lines of PowerShell casting each file to [xml] and writing the fields to a CSV will get most people a long way. This costs nothing but your time, and it is a completely legitimate answer.

3. Unpack the template by hand (free, technical)

Because .xsn is a CAB archive, you can extract it and read the parts inside: expand form.xsn -F:* C:\out on Windows, or a general archive tool that understands CAB. That gets you the schema and the view transforms, which is how you work out what a field path means. We have written that up in full.

4. A migration project (bigger, costs more)

If these forms are still live business processes, rebuilding them on a modern platform is the right answer for the process. It is a project, and it is a separate job from preserving the records already filled in. Migration and archival are not the same task and one does not do the other.

5. A local, read-only reader (what we make)

XSN Rescue exists for the case where the manual routes have run out of road — a folder of records, no InfoPath, and a need for something an auditor can open in five years. It reads .xsn and .xml files on your own machine, opens them read-only, and exports the field data to CSV, JSON and HTML, with a self-contained archival PDF per record and a recovery report on every run stating what came out and what did not.

What it does not do, so there are no surprises. It recovers the data and the static layout. It does not execute or recover code-behind, external data connections or user-role logic; digital signatures are surfaced as fields but not cryptographically verified; and the archival PDF uses a standard Latin font, so characters outside that set are marked [U+XXXX] and counted — the JSON export keeps the exact text either way. The recovery report states this per file.

Platform. XSN Rescue runs on macOS (10.15 or later, Intel and Apple silicon, one universal download) and on Windows 10 and 11 (64-bit). Both are the same version and the same price — one purchase covers both. There is no Linux build, and we are not giving a date for one; on Linux, the free routes above are your path, and they work.

The short version

  1. Read the exact error — the four common ones have different causes.
  2. Clear the template cache first; it is free, reversible, and fixes a surprising share of cases.
  3. Check the href at the top of the record's XML — a dead template location is a very common cause.
  4. Work only from copies. Never let a repair or a conversion touch your originals.
  5. If the records matter for retention or audit, get the data into open formats now, by whichever of the routes above fits your scale.

We would genuinely rather you fixed this with a cache clear and a text editor than paid anyone, including us. Losing the records is the only bad outcome here.