Fixing Siemens NX 'General Fault Exception' on Startup

Fixing Siemens NX "General Fault Exception" on Startup

I've lost count of how many support tickets start with the same sentence: "NX was working yesterday, and today it won't even open." The error message — General fault exception — is deliberately vague. It tells you the process crashed during initialization but doesn't point to the culprit. Over the past three years of administering NX installations across university labs and enterprise environments, I've developed a systematic approach that resolves this in under 30 minutes in the majority of cases.

Understanding What "General Fault Exception" Actually Means

When NX launches, the ugraf.exe process goes through a sequence of initialization steps: license checkout, graphics subsystem probe, user profile loading, and UI rendering. The "General fault exception" typically occurs at the graphics subsystem probe or during the loading of Microsoft Visual C++ runtime libraries. The error is a catch-all for an unhandled exception in the initialization chain — it's not a single bug, it's a symptom class.

The Siemens community forum has dozens of threads on this. One user reported the error on a Dell XPS with an NVIDIA GeForce 1650 Ti, noting that NX "is not certified on GeForce graphics cards" but should still run with reduced performance. Another user discovered their Windows account name contained Korean characters, which broke NX's path resolution. Both cases share a root cause: something in the initialization environment is incompatible or missing.

Step 1: Check the Syslog First

Before changing anything, look at the syslog. NX writes diagnostic logs to your %TMP% directory every time it attempts to start.

1. Open File Explorer and navigate to %TEMP% (paste this directly into the address bar)
2. Look for files named syslog or syslog_<timestamp>
3. Delete all existing syslog files
4. Attempt to launch NX again
5. Open the new syslog file in a text editor

The syslog will contain lines like:

*** GENERAL FAULT detected in module: gdi_graphics.dll
*** Exception code: 0xC0000005 (Access Violation)

This tells you exactly which module crashed. If it's a graphics-related DLL, proceed to Step 2. If it's a runtime library, skip to Step 3.

Step 2: Graphics Driver — The Most Common Culprit

NX uses OpenGL for its graphics pipeline. The certified driver list on Siemens' website is narrow — it covers Quadro, Radeon Pro, and a handful of Intel Iris variants. GeForce and consumer Radeon cards are unsupported, but they usually work if the driver is stable.

The Fix

1. Download the driver directly from NVIDIA or AMD — do not use the Windows Update driver. Windows Update often installs a stripped-down driver that lacks the OpenGL ICD (Installable Client Driver) NX needs.
2. Perform a clean installation using DDU (Display Driver Uninstaller) if you're updating:
   • Boot into Safe Mode
   • Run DDU to remove all traces of the previous driver
   • Reboot and install the fresh driver
3. Set NX to use Software OpenGL as a test:
   • Set the environment variable UGII_OPENGL_VERSION to software
   • If NX launches successfully, you've confirmed the graphics driver is the issue
   • Remove the variable once you've installed a working driver

I had one case where a user's GeForce driver auto-updated through NVIDIA Experience and broke NX overnight. Rolling back to the previous driver resolved it immediately. The lesson: disable auto-updates for graphics drivers on NX workstations.

Step 3: Repair Microsoft Visual C++ Redistributables

NX depends on specific versions of the MSVC runtime. The exact version depends on your NX release:

• NX 12 through NX 1899: MSVC 2015 Redistributable (x64)
• NX 2007 through NX 2206: MSVC 2017 Redistributable (x64)
• NX 2306 and later: MSVC 2019 Redistributable (x64)

If these get corrupted — often by a Windows update or another software installation — NX will crash on startup with a general fault.

The Fix

1. Go to Control Panel → Programs and Features
2. Find the relevant Microsoft Visual C++ Redistributable
3. Right-click and select Change, then Repair
4. Reboot after the repair completes
5. If repair doesn't work, uninstall and reinstall from Microsoft's official download page

One user on the Siemens forum reported that their NX installation failed because the MSVC redistributable wasn't installed at all — their university's deployment script had skipped the prerequisites. Running the NX installer's prerequisite checker revealed the missing component.

Step 4: Check for Non-ASCII Characters in User Profile Path

This is an obscure but real issue. NX writes temporary files and configuration data to %LOCALAPPDATA%\Siemens\NX<version>. If your Windows username contains non-ASCII characters (Korean, Chinese, Cyrillic, accented Latin), the path resolution can fail silently.

A user on the Siemens forum discovered this exact problem: their Windows account name was in Korean, and NX refused to start. After changing the account name to English, NX launched without issue.

The Fix

1. Check your Windows username: echo %USERNAME% in Command Prompt
2. If it contains non-ASCII characters, create a new Windows user account with an English-only name
3. Alternatively, set the UGII_TMP_DIR environment variable to a path with only ASCII characters (e.g., C:\nxtemp)

Step 5: Clear the NX User Profile

If NX was working and suddenly stopped, the user profile may be corrupted. The profile stores UI customization, recent files, and display settings.

1. Close NX
2. Navigate to %LOCALAPPDATA%\Siemens\NX<version> (e.g., C:\Users\yourname\AppData\Local\Siemens\NX2306)
3. Rename the folder to NX<version>_backup
4. Launch NX — it will create a fresh profile

If NX starts successfully, you've confirmed profile corruption. You can try restoring specific settings from the backup folder, but I recommend starting fresh to avoid re-introducing the corruption.

Step 6: Verify License Server Connectivity

If you're using a floating license, NX will hang or crash if it can't reach the license server. The error message may not explicitly mention licensing — it can manifest as a general fault.

1. Open Command Prompt and run: ping <license-server-hostname>
2. Check the license server port: telnet <license-server-hostname> 28000
3. Verify the SPLM_LICENSE_SERVER environment variable is set correctly: echo %SPLM_LICENSE_SERVER%
4. If you've borrowed a license, check that the borrow hasn't expired: run ugslmd -borrow_status in the license server tools

One forum user reported that NX became unresponsive after borrowing a license — it would freeze every 5-10 minutes because the license manager was pinging the server in the background and timing out. The only real fix was to return to the same network as the license server.

When to Contact GTAC

If none of these steps resolve the issue, it's time to open a support ticket with GTAC (Global Technical Access Center). Before you call:

• Zip the syslog file from %TMP%
• Note your exact NX version (Help → About NX, or check ugii_root in the installation directory)
• Note your graphics card model and driver version
• Note your Windows version (run winver)

Having this information ready will save you 20 minutes on the phone. GTAC can also provide hotfixes for known bugs that haven't been released in a public update yet.

Summary

The "General fault exception" is almost always caused by one of four things: a broken graphics driver, a corrupted MSVC runtime, a non-ASCII user profile path, or a license server connectivity issue. By checking the syslog first, you can identify which module is failing and target your fix accordingly. In my experience, the graphics driver is responsible for about 60% of cases, the MSVC runtime for 20%, and the remaining 20% split between profile corruption and licensing issues.