Skip to main content

Troubleshoot Assertion failure: instance.GetRef()

An FXServer error may include text resembling:

Assertion failure: instance.GetRef()
.../code/client/shared/Registry.h:...

Copy the exact message from your console or crash log. The original article's title used GetRed() while its body used GetRef(); this page covers GetRef().

This assertion alone does not prove that the server contains malware. It also does not establish that Windows must be reinstalled. The upstream registry implementation asserts that a requested instance reference is available; the complete log and reproduction steps are needed to investigate why startup reached that state.

1. Preserve the error and recent changes​

Before modifying files, record:

  • The complete error, including its source file and line number.
  • FXServer artifact build and operating system.
  • txAdmin version and how the process is launched.
  • Whether the failure began after an artifact, theme, resource or OS update.
  • Whether custom binaries or modified system resources are installed.
  • Startup output immediately before the assertion and available crash details.

The source path printed inside a compiled assertion can refer to the developer's build machine. It is not automatically a path you should create on your own computer.

Back up server configuration, resources and persistent data before replacing an installation.

2. Test clean official artifacts separately​

  1. Stop the affected process gracefully.
  2. Download official artifacts for the operating system from the links below.
  3. Extract them into a new directory instead of layering them over the existing installation.
  4. Keep the original installation intact for comparison and rollback.
  5. Test with an isolated development profile and minimal configuration.
  6. Keep custom themes and third-party resources out of the initial test.
  7. Avoid launching a second instance against the live profile, same database or conflicting ports.

A compiled theme package includes version-specific interfaces. First confirm stock txAdmin works before introducing a matching theme again.

Official artifact downloads​

Use the artifact guidance published by Cfx.re and your host. Keep the exact failing and test build numbers in your notes.

3. Compare the results​

Clean startup works​

The difference between the clean test and the original environment is useful evidence, but does not immediately identify one particular file as the cause.

Reintroduce configuration and resources in controlled stages on the test installation. Record when the assertion returns. Check version compatibility and recent changes before assuming malicious activity.

Clean startup still fails​

Preserve that result along with your OS details, launch command, build number and complete logs. Ask your host or Cfx.re support/community for help with the reproducible clean case.

Do not repeatedly reinstall random components or remove all resources from production without preserving a working backup and a clear test plan.

4. Investigate suspected file modification​

If there is independent evidence of compromise—for example, unexplained changes to trusted runtime files—compare them against clean files from the same official release.

The supplied 8.1.1 package uses:

monitor/entrypoint.js

The original article mentioned entrypoints.js, which is a different filename. Verify the actual installation instead of relying on that typo.

A .js extension, minified source or obfuscation alone is not proof of a backdoor. Legitimate release bundles, including txAdmin's compiled backend and interfaces, may be large or minified.

Do not run suspicious code to see what it does, and do not upload files containing credentials to public analysis sites. Ask a qualified reviewer to examine unexplained modifications if you cannot establish their origin.

5. If compromise is confirmed​

Treat recovery as a host-security incident rather than only a theme problem:

  1. Isolate the affected host or service as appropriate to stop ongoing access.
  2. Preserve relevant evidence and logs before cleanup.
  3. Use a trusted device to revoke or rotate exposed credentials and tokens.
  4. Identify how the compromise occurred and which data or backups may be affected.
  5. Restore from a known-good state or rebuild the host when its integrity cannot be trusted.
  6. Restore only reviewed resources and data, then monitor for recurrence.

A full host rebuild may be appropriate for confirmed compromise. It is not the default response to the assertion message by itself, and replacing artifacts alone is not sufficient if the wider host is compromised.

6. Request help with a useful report​

Include:

  • Exact assertion text and surrounding log output.
  • FXServer artifact build, txAdmin version and OS version.
  • Recent changes and the source of your artifacts.
  • Whether the error reproduces using clean official artifacts and an isolated profile.
  • Any verified unexpected modifications, clearly separated from suspicions.

Remove server keys, passwords, tokens and private player data before sharing logs.

About the original screenshots​

The pasted source referenced screenshots of the error and allegedly injected code, but the images were not included. This page does not treat those unavailable screenshots as proof or embed broken image links.

If you later add images, redact secrets and explain exactly what each image demonstrates.

References​

These references explain the assertion's context; they do not diagnose the cause on a particular server.