Resolving Ignition 8.3 Perspective Missing from Designer

In this case, the Perspective node was missing from the Ignition 8.3 (beta / early access) Designer project browser on a physical host. The same 8.3 build showed Perspective normally inside a VM. The Perspective module on the host gateway was activated and starting in Trial mode. The Designer's embedded Chromium engine (JxBrowser 8.5.0) was crashing on launch. Because the VM worked and the host did not, the fault sits in the workstation environment: security software, process-creation policy, or a corrupted per-user cache. The project and gateway configuration are not the cause.

Work through the checks below in order. Each check names the reading to take, what each result means, and where to go next.

Check 1: Perspective module state and gateway sign-in

Prerequisite: gateway web interface access with an administrator account.

1. Sign in to the 8.3 gateway web page before you judge what is missing. In 8.3, an unauthenticated session hides most of the gateway navigation. After an install from the zip package, the gateway looked like it was missing whole sections of its menu until the user signed in. This is a change in behavior from 8.1. Confirm the full navigation appears after login.
2. Open the module list on the gateway. Confirm Perspective is installed and running, and that its license state is Activated or Trial.
3. Launch the Designer against that gateway. Confirm the console shows Starting module: Perspective, followed by Starting up Perspective module. Mode: Trial (or the licensed mode).

Check 2: BrowserEngine error in the Designer console

The Perspective Designer renders and edits views inside an embedded Chromium instance supplied by JxBrowser. If that engine does not initialize, the Perspective workspace never registers. The project browser then shows every other resource type but no Perspective node. The Vision module also uses this engine for its Web Browser component. For that reason, the Vision startup log runs the same JxBrowser binary integrity check as Perspective.

1. Launch the Designer as a standard user and open its console.
2. Do not stop at the first error shown. In this case the first error was unrelated. Read the full console content that follows it.
3. Look for this line:

   [Designer-Startup] ERROR WebBrowser -- BrowserEngine was not initialized. Web Browser Component can not start!

Check 3: JxBrowser DEBUG logging through Designer Launcher JVM arguments

The default console shows only that the engine failed, not why. JxBrowser writes its own startup trace when its log level is raised. How much that trace shows depends on JxBrowser's own logging.

1. Close every Designer instance.
2. In the Designer Launcher, open the settings for the gateway entry and find the JVM Arguments field.
3. Add:

   -Dignition.client.jxBrowser.logLevel=DEBUG

4. Relaunch the Designer. Confirm the console now shows DEBUG lines such as Acquiring an exclusive lock..., Checking binaries integrity in ...\.ignition\cache\resources\jxbrowser\8.5.0... and Using WIN64 listing....
5. Copy the console as text, not screenshots. You need the full sequence to find the exit lines in Check 4.

If you add more than one argument, separate them with a semicolon on a single line. Putting the second argument on a new line in the JVM Arguments field made the Designer fail to launch with an error dialog. Removing the line break fixed it, and so did removing the first argument.

-Dignition.client.jxBrowser.logLevel=DEBUG;-Dignition.chromium.switch.do-not-de-elevate

Check 4: The Chromium exit sequence in the DEBUG log

In this case, every file under %USERPROFILE%\.ignition\cache\resources\jxbrowser\8.5.0 passed the integrity check. That includes libEGL.dll, libGLESv2.dll, vulkan-1.dll, awt_toolkit64.dll, chrome.dll.sig, resources.pak and the locales packs. The binaries on disk were intact, so the failure happened when the Chromium process was launched or while it was running. It was not a missing-file problem. Scroll past the Checked lines to the end of the JxBrowser block:

DEBUG Closing RPC thread...
DEBUG The connection has been terminated.
DEBUG Closing RPC thread... [OK]
DEBUG Chromium process exit code: -2,147,483,645
DEBUG Stopping server...
DEBUG Stopping server... [OK]

A connection that is terminated from outside, followed by a crash exit code, points to something external interfering with the Chromium process. The binaries themselves are fine. Continue to Check 5 to rule out elevation, which is the quickest variable to change.

Check 5: Elevation and the do-not-de-elevate switch

Chromium treats an elevated (administrator) parent process differently from a standard one. When the host application runs elevated, the Chromium launch path can try to start its child processes at a lower integrity level. If a policy or shim interferes with that step, the child dies at startup.

1. Confirm how the Designer Launcher was started. Run it as a standard user, not with "Run as administrator". In this case both modes produced the same failure, so leave it running as a standard user.
2. Add the de-elevation override next to the DEBUG argument, on one line with a semicolon:

   -Dignition.client.jxBrowser.logLevel=DEBUG;-Dignition.chromium.switch.do-not-de-elevate

3. Relaunch the Designer. Confirm it opens at all. A launch error dialog means a line break is in the field. Then re-read the console for BrowserEngine was not initialized and the exit code.
4. Check the user and system environment variables for the Windows compatibility setting ElevateCreateProcess. A compatibility layer that changes how processes are created can break Chromium's child-process launch. Remove it for the test if it is present, and record whether it was set.

Check 6: Antivirus and endpoint security interference

Antivirus is the most common reason the JxBrowser engine crashes. TeamDev's JxBrowser troubleshooting guide for frequently encountered issues lists it first. Endpoint products inject DLLs into new processes and hook process creation. Chromium's sandbox and code-integrity checks react badly to both. A VM that works next to a host that fails usually means the host carries an endpoint agent or policy that the VM does not.

1. Prerequisite: coordinate with IT. On managed machines you cannot usually change security policy yourself.
2. Ask IT to check the security console for blocks or detections against the Designer's Java process, the Chromium executable under the JxBrowser cache, and anything under %LOCALAPPDATA%\JxBrowser or %LOCALAPPDATA%\Temp.
3. Have AV disabled, then relaunch the Designer with DEBUG logging still on. Compare the exit sequence with the previous run.
4. If disabling alone does not change the result, ask IT to add exclusions for the Ignition cache and JxBrowser paths and reboot. Many endpoint agents leave their drivers and injected hooks loaded when protection is only switched off. A disabled product can still be inside the Chromium process until the next restart or a full uninstall.
5. Ask IT which features beyond signature scanning are active: application control, exploit protection, behavior monitoring. These can block or crash a child process without writing an AV detection event.

In this case, IT first reported no logged block. That alone is not a reason to rule the product out. AV was later identified as a culprit, but the Designer still failed with AV disabled. That combination means a second environmental factor is involved. It can also mean the disabled agent is still resident. Continue to Check 7 with AV still disabled.

Check 7: Purging the Ignition JxBrowser cache

The Designer extracts the JxBrowser runtime into the per-user Ignition cache. If a security product quarantined, locked or partially rewrote files there during an earlier failed launch, the cache can stay damaged even after the product is disabled. Warnings about DLL files in the console are a reason to purge it.

Prerequisites: AV still disabled, every Designer and Designer Launcher window closed, and the local gateway service stopped if the gateway runs on the same machine.

1. Open Task Manager. Confirm no Java or Chromium processes from a previous Designer session are still running. End any leftovers.
2. From an elevated PowerShell prompt, delete the whole cache directory:

   Remove-Item -Recurse -Force "$env:USERPROFILE\.ignition\cache"

3. Confirm the directory is gone:

   Test-Path "$env:USERPROFILE\.ignition\cache"

   The expected result is False.
4. If deletion fails with "in use" errors, reboot the workstation first, then repeat step 2 before launching anything Ignition-related. In this case, forced deletion from elevated Command Prompt and PowerShell both failed while a process held the files. Partial deletion is not acceptable. A cache that is left half-deleted keeps the Perspective failure in place.
5. Relaunch the Designer. Confirm the console shows a fresh extraction and integrity check under jxbrowser\8.5.0, then read the exit sequence again.

Check 8: JxBrowser-UserData folder in the Temp directory

A healthy JxBrowser startup creates a Chromium profile directory in the user's Temp folder, named with a GUID suffix, for example JxBrowser-UserData-1a76bb6d-0fa8-4b4d-ad3a-63be0cd9674a. The directory appears while the Designer is launching and the engine is starting.

1. Launch the Designer and wait for the Perspective module startup line in the console.
2. Check for the profile folder:

   Get-ChildItem "$env:LOCALAPPDATA\Temp" -Filter "JxBrowser-UserData-*" -Directory

3. If none exists, create a test folder manually in %LOCALAPPDATA%\Temp as the same Windows user. The name does not matter. This tests only whether the user has write rights there.

A missing profile folder when the user can write to Temp points to the child process being blocked or crashing very early. Because of the timing, security policy and process-creation restrictions are more likely causes than file permissions.

Check 9: Chromium crash dumps in WinDbg

When the Chromium child crashes, it writes minidumps to:

%LOCALAPPDATA%\JxBrowser\8.5.0\CrashReports

1. Copy the newest .dmp files out of that folder, sorted by timestamp to match your last launch.
2. Open each dump in WinDbg and run:

   !analyze -v
   k
   lm

3. Record the faulting symbol, the call stack, and the full loaded-module list.

In this case the analysis reported chrome!CrashForExceptionInNonABICompliantCodeRange. Chromium on 64-bit Windows registers this handler for exceptions raised inside dynamically generated code, such as JIT output. That code has no standard unwind data, so Chromium converts any exception there into an intentional crash. The symbol tells you where Chromium caught the exception, not what caused it. Several different root causes produce the same symbol.

The lm output is the most useful part of the dump. Compare it against a dump or module list from the working VM, if you can collect one. Look for DLLs that do not belong to Windows or JxBrowser, especially security, monitoring, screen-capture or overlay products. A third-party module injected into the Chromium process is the usual explanation when disabling AV does not fix the crash: the agent's hooks are still loaded.

Reinstall path, escalation package, and final Designer verification

Reinstalling Ignition rarely fixes this failure. The engine crash comes from the workstation environment, not the gateway install. If you do reinstall to rule it out, switch installer types: use the zip package if you used the executable, or the reverse. After a zip install, sign in to the gateway before you judge whether pages are missing (Check 1). Uninstalling and reinstalling everything again, after the cache purge and Temp checks have failed, does not add information.

If the crash persists after Checks 5 through 9, collect the following and send it to Inductive Automation support. They can forward JxBrowser-level crashes to TeamDev, the JxBrowser vendor.

1. The full Designer console as text from a launch with -Dignition.client.jxBrowser.logLevel=DEBUG, including the Chromium process exit code line.
2. The matching dumps from %LOCALAPPDATA%\JxBrowser\8.5.0\CrashReports, plus your WinDbg !analyze -v and lm output.
3. The exact Ignition 8.3 build, the Windows version and build, the endpoint security products installed (and whether each was disabled or uninstalled during the test), and whether ElevateCreateProcess was set.
4. The fact that the same build works in a VM on the same network, and whether a JxBrowser-UserData-* folder appears in Temp.

When a branch resolves the crash, verify it in this order:

1. Close all Designers. Remove -Dignition.chromium.switch.do-not-de-elevate from the JVM Arguments unless Check 5 proved you need it. Then remove the DEBUG argument so later logs stay readable.
2. Relaunch the Designer as a standard user. Confirm the console shows Starting up Perspective module and has no BrowserEngine was not initialized line.
3. Confirm a JxBrowser-UserData-* folder exists in %LOCALAPPDATA%\Temp while the Designer is running, and that no new dump appeared in CrashReports.
4. Re-enable AV with the agreed exclusions in place, reboot, and repeat steps 2 and 3.
5. Open the project and confirm the Perspective node appears in the project browser. Open an existing view and confirm it renders in the workspace editor.

FAQ