MS Word Automation Troubleshooting
dramat.eu
Home » Word Automation Troubleshooting Deutsch

This page collects everything we know about the Documentation Generator Pro plugins (VKRC, ABB, Fanuc) failing to generate a Word document, beyond the ActiveX blocking described on each plugin's own page. All three plugins drive MS Word through the same COM/OLE automation interface, so the causes and fixes below apply equally to all of them, and to the same kind of problem in any application that automates Word/Excel/PowerPoint from the outside – not just this plugin.

This page is written so that you can follow it step by step even if you have never used the Windows Registry, PowerShell or the Command Prompt before. Every technical term is explained the first time it is used, and every action tells you exactly which key to press or which button to click. Please read "Before you start" first – it explains a few things (Administrator rights, PowerShell, the Registry Editor) that come up several times later on the page.



▲ Before you start – a few things explained once

The steps further down this page ask you to open a few Windows tools that not everyone uses every day. Here is exactly how to open each one. Whenever a later step says "open an elevated Command Prompt" or "open PowerShell" or "open the Registry Editor", come back to this section if you forget how.

What does "Administrator" / "elevated" mean?

Windows normally runs programs with limited rights, so that a program cannot change important system settings by accident. "Running as Administrator" (also called "elevated") means you are giving that one program permission to make bigger changes – for example, changing whether a driver is allowed to start. You will know it worked because Windows will pop up a dialog titled "User Account Control" asking "Do you want to allow this app to make changes to your device?" – click Yes. If you don't see that dialog after right-clicking and choosing "Run as administrator", it may already have appeared and disappeared, or your account may not have administrator rights on this computer (ask whoever manages the PC).

How to open an elevated ("Administrator") Command Prompt
  1. Press the Windows key on your keyboard (or click the Start button, the Windows logo in the taskbar).
  2. Type cmd (you do not need to click anywhere first, just start typing – a search box appears automatically).
  3. In the search results, you will see "Command Prompt". Instead of clicking it normally, right-click on it.
  4. In the menu that appears, click "Run as administrator".
  5. If a "User Account Control" dialog appears asking for permission, click Yes.
  6. A black window opens with a title bar that says "Administrator: Command Prompt" – the word "Administrator" in the title confirms it is elevated. This is the window later steps mean when they say "elevated Command Prompt".

How to open PowerShell

PowerShell is another, more modern command window, used later on this page to reproduce the error with a short script. You open it almost the same way:
  1. Press the Windows key.
  2. Type powershell.
  3. Click "Windows PowerShell" in the search results (a normal left-click is enough for this one, unless a step explicitly says to run it as administrator – in that case right-click it and choose "Run as administrator" instead, the same way as for the Command Prompt above).
  4. A blue (or dark) window opens where you can type commands. To run a command, type or paste it, then press Enter.
  5. To paste a script that was copied from this page: click once inside the PowerShell window so the cursor is there, then right-click – this pastes the clipboard content directly. If you pasted several lines at once, press Enter once more afterwards to make sure the last line runs.

How to open the Registry Editor (regedit)

The Registry is a big settings database used internally by Windows and by installed programs. You will only be asked to look at, and sometimes delete, a couple of very specific, clearly-named entries – not to change settings freely.
  1. Press the Windows key.
  2. Type regedit and press Enter.
  3. If a "User Account Control" dialog appears, click Yes – the Registry Editor always needs Administrator rights.
  4. A window titled "Registry Editor" opens, with a tree of folders on the left (starting from "Computer") similar to Windows Explorer.
  5. To navigate to a path such as HKLM\SOFTWARE\Microsoft\Office\Word\AddIns: click the little arrow next to Computer, then HKEY_LOCAL_MACHINE (this is what HKLM is short for), then keep clicking the arrows next to SOFTWARE, then Microsoft, then Office, then Word, then finally click on the AddIns folder itself so its contents show up on the right.
  6. Instead of clicking through every folder by hand, you can also click once on Computer at the very top, then paste the whole path (for example Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Word\AddIns) into the address bar at the top of the window (it works like a browser's address bar) and press Enter.
  7. To delete a folder (a "key") once you have found it: right-click on its name in the left-hand tree, choose Delete, and confirm by clicking Yes when Windows asks "Are you sure you want to permanently delete this key and all of its subkeys?". Only delete the exact key named in the instructions – do not delete parent folders like "AddIns", "Word" or "Office" themselves.
  8. To search for a name anywhere in the Registry: click on Computer at the very top of the tree first (so the search covers everything), then press Ctrl+F, type the name you are looking for, and click Find Next. If the result is not the one you want, press F3 to jump to the next match.


▲ Symptoms

Depending on exactly where the automation gets interrupted, you may see any of the following: That last point is the most useful diagnostic signal: if creating a blank document works but opening an existing file does not, the problem is not really about templates, fonts, or file corruption at all – something is specifically intercepting the "automated process opens an existing file" operation.


▲ Cause 1 – ActiveX disabled by default since 2024

Starting in 2024, Microsoft disabled ActiveX controls by default in Microsoft 365 and Office 2024 (see Microsoft's official announcement). This specifically affects the recursiveimg tag with an *.xlsx filter (it embeds a live MS Excel worksheet as an ActiveX/OLE object). The full explanation and workarounds for this specific cause are on each plugin's own documentation page, in the red warning box at the top: VKRC · ABB · Fanuc.

If you have already applied those workarounds (Trust Center ActiveX setting, avoiding *.xlsx in recursiveimg, "MS Office interactive mode") and generation with a template file still fails the same way, ActiveX is probably not your problem – keep reading.


▲ Cause 2 – security or rights-management software blocking automated file access

Modern antivirus, EDR (endpoint detection & response) and enterprise Information Rights Management (IRM) / DLP products increasingly treat "an external process drives Word/Excel through COM automation and tells it to open a file" as a suspicious pattern – because that is exactly how a number of document-based malware and data-exfiltration techniques work. Some of these products react by silently killing the Office process the moment it tries to open an existing file this way, which is precisely the failure pattern described above.

This is very difficult to diagnose from the plugin's side, because:

▲ Real case study – a decade-old orphaned NextLabs driver

In September 2026 we traced exactly this failure (HRESULT 0x800706BE, template-only, both Word and Excel affected, blank documents always worked) on a real, private (non-corporate) laptop. Every "obvious" suspect was ruled out one by one: the template file itself (identical failure on a brand-new blank .doc), ActiveX Trust Center settings (already fully permissive), Office licensing, a specific Windows update some users had reported online, leftover ("zombie") WINWORD.EXE processes, running as Administrator, a corrupted Word user profile, DCOM Launch/Activation permissions (nothing relevant in Event Viewer), Controlled Folder Access, an Office Online Repair, the COM registration of Word.Application itself, Word's COM add-ins, and its STARTUP template folder. The installed antivirus (Norton 360) looked very promising for a while – Process Monitor showed it injecting a hook DLL into WINWORD.EXE – but disabling it completely, and separately disabling each of its advanced protection modules one by one, made no difference at all.

The actual cause only surfaced by inspecting the exact moment WINWORD.EXE terminated in Process Monitor (see below for the full step-by-step walkthrough of how this was found): its Process Exit event showed an unusual, non-standard exit code (-536870910, i.e. 0xE0000002 in hex – not a typical Windows crash code like an access violation, which is a strong sign of a deliberate termination by something else rather than a real application crash), and its list of loaded modules included nxrmcore64.dll from NextLabs, Inc., a commercial enterprise Information Rights Management product. Further digging in the Registry (see how to open and search the Registry Editor above) found: A kernel-mode driver like this can intercept file-open operations system-wide, which explains every single observation: it affected Word and Excel identically, it did not matter which folder the file was in, it was completely unrelated to Norton, and none of the ordinary places you would check (installed programs, services list, DCOM permissions, Word's own add-in list) showed anything obviously wrong.

How it was fixed, step by step:
  1. Opened the Registry Editor (Windows key » type regedit » Enter » click Yes).
  2. Navigated to HKLM\SOFTWARE\Microsoft\Office\Word\AddIns\NxRMAddin (Computer » HKEY_LOCAL_MACHINE » SOFTWARE » Microsoft » Office » Word » AddIns » NxRMAddin), right-clicked NxRMAddin and chose Delete, then confirmed.
  3. Repeated the same deletion for HKLM\SOFTWARE\Microsoft\Office\Excel\AddIns\NxRMAddin and HKLM\SOFTWARE\Microsoft\Office\PowerPoint\AddIns\NxRMAddin.
  4. Opened an elevated ("Administrator") Command Prompt (Windows key » type cmd » right-click "Command Prompt" » "Run as administrator" » click Yes).
  5. In that black window, typed the following command and pressed Enter – this tells Windows to stop starting the nxrmdrv driver from now on:
    sc config nxrmdrv start=disabled
    The Command Prompt replied with [SC] ChangeServiceConfig SUCCESS. (An attempt to stop it immediately with sc stop nxrmdrv returned error 1052 – this particular driver did not support being stopped while running, only disabled for the next boot, which is fine since the next step restarts the computer anyway.)
  6. Restarted the computer normally (Start menu » Power » Restart), so the driver would not be loaded again.

After the restart, Documents.Open() through COM automation worked immediately, and all three plugins generated documentation normally again.

The point of this case study is not that you have NextLabs on your machine – it is extremely unlikely you do. The point is that some long-forgotten piece of security or rights-management software, possibly installed years ago for an entirely different project or client and never fully removed, can silently keep intercepting Office automation on your machine without leaving any obvious trace. The diagnostic method below is what actually finds it, regardless of which product turns out to be responsible for you – you are looking for your own suspect name in Process Monitor, not for "NextLabs" specifically.


▲ How to diagnose it yourself with Process Monitor

Process Monitor (ProcMon) is a free, official Microsoft/Sysinternals tool that logs every file, registry and process event on your system in real time. It is the single most useful tool for this kind of problem, because it shows you exactly what happens in the moment the automated Word/Excel process dies, which nothing else does. None of the steps below require any programming knowledge – just follow them in order.
  1. Open the link above in your browser and click Download Process Monitor. This downloads a ProcessMonitor.zip file (usually into your Downloads folder).
  2. Open your Downloads folder in File Explorer, right-click ProcessMonitor.zip, and choose Extract All..., then click Extract in the dialog that appears. This creates a new folder with several files inside it.
  3. Open that new folder and find Procmon64.exe (on very old 32-bit Windows it would be Procmon.exe – almost every computer today is 64-bit). Right-click it and choose "Run as administrator", then click Yes if Windows asks for permission – Process Monitor needs this to see everything happening on the system.
  4. The first time it runs, it may show a licence agreement – click Agree. A window with a lot of scrolling text (file and registry activity from your whole computer) appears immediately; this is normal, you do not need to read any of it yet.
  5. Clear out everything that was captured before you started watching, so the log only contains what happens next: click inside the Process Monitor window, then press Ctrl+X (or use the menu: Edit » Clear Display).
  6. Make sure it is actively recording: press Ctrl+E once (or use File » Capture Events in the menu). If capturing was already on, this will turn it off – look at the toolbar icon that looks like a magnifying glass; if it is highlighted/pressed-in, capturing is on. If in doubt, press Ctrl+E again until the magnifying glass icon looks "pressed in".
  7. Now reproduce the failure. The easiest way is to simply try generating documentation with the plugin again, the way you normally would. If you prefer to reproduce it directly, without the plugin, you can use a short script instead:
    1. Open PowerShell (see how, above – a normal, non-administrator PowerShell window is fine for this test).
    2. Copy the three lines below (select the text with your mouse, then Ctrl+C).
    3. Click inside the PowerShell window, right-click once to paste all three lines at once, then press Enter.
    4. Replace C:\path\to\some_existing_file.doc with the real path to any Word document you already have on your computer before pasting (for example one of your own generated documents, or any .doc/.docx file you can find).
    $word = New-Object -ComObject Word.Application
    $word.Visible = $true
    $doc = $word.Documents.Open("C:\path\to\some_existing_file.doc")
    If the problem described on this page affects you, this will fail with a red error message mentioning 0x800706BE a few seconds after you press Enter, and Word will not actually show the document (it may flash briefly or not appear at all).
  8. As soon as the error appears (or the plugin shows its own error dialog), switch back to the Process Monitor window and press Ctrl+E again to stop capturing, so the log does not keep filling up with unrelated activity.
  9. Press Ctrl+F to open the Find box. Type Process Exit (exactly like that, with the capital letters and the space) and click Find Next. Process Monitor will jump to the first matching row and highlight it.
  10. This is likely not the right one yet – your computer exits many small helper processes all the time. Look at the Process Name column of the highlighted row. If it does not say WINWORD.EXE (or EXCEL.EXE, if you are testing Excel), press F3 to jump to the next match, and keep pressing F3 until the Process Name column shows WINWORD.EXE.
  11. Once you have found the right row, close the Find box and double-click that row to open its Event Properties window.
  12. In that window, click the Event tab (it is usually selected by default) and find the field labelled Exit Status. Write down the number you see there.
    • A recognisable Windows crash code such as 0xC0000005 ("access violation") suggests a real application bug or a damaged file, and this page's diagnosis probably does not apply to you.
    • An unusual number that does not look like a typical crash code (in the case above it was -536870910, which is the same as 0xE0000002) is a strong sign that something else deliberately closed Word, which is exactly the pattern this page is about – keep going.
  13. Now click the Process tab in the same Event Properties window. Scroll down to the Modules list (this shows every file that was loaded into Word while it was running). Look at the Company/Description columns for each row, and look specifically for anything that is not a standard Microsoft file (Microsoft's own files normally say "Microsoft Corporation" in the Company column). Any other company name here is your suspect – write it down.
  14. Once you have a suspect name (a company or product name from the Modules list), open the Registry Editor, click once on Computer at the very top of the tree on the left (so the whole registry is searched, not just one folder), press Ctrl+F, type that name, and click Find Next. Press F3 to keep jumping to further matches. You are looking for entries under paths such as HKLM\SOFTWARE\Microsoft\Office\Word\AddIns\..., HKLM\SOFTWARE\Microsoft\Office\Excel\AddIns\..., or HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DIFx\DriverStore\..., mentioning that company or product name.
  15. If you find a Driver Store entry, it will usually mention a service name as well. Open an elevated Command Prompt and type (replacing <servicename> with the real name you found):
    sc query <servicename>
    and press Enter. If the reply includes KERNEL_DRIVER and RUNNING, you have found a background driver that is very likely the real cause – the fix is the same pattern as the case study above: remove the leftover Office add-in registry entries for that product, then disable its driver with
    sc config <servicename> start=disabled
    in the same elevated Command Prompt, and restart the computer.


▲ General checklist

In roughly the order worth trying, from quickest to most involved: