Debugging Server Exceptions

Intermediate40-60 minutesWindowsUnturned ServerNotepad++

Debugging exceptions in a release build of the Unturned™ dedicated server is more difficult than debugging in a development environment because the release binary contains no source mappings, no local variable names, and no line number information. The stack trace that the server prints to the log file shows method names and IL offsets but not the source file lines that would immediately tell a developer where the failure occurred. The technique for bridging this gap -- converting the IL offset back to a source code location -- is the subject of this article.

The method was contributed by the community member DiFFoZ and is summarized here for the benefit of all Unturned™ server operators and plugin developers who need to diagnose exceptions in the server process. The approach uses the IL offset that Unity logs in square brackets within the Player.log file, combined with a .NET decompiler that can display the assembly's IL code alongside the decompiled C# source.

This article is the 57 Studios™ reference for server-side exception debugging. It covers locating the IL offset in the Player.log stack trace, identifying the correct assembly, using ILSpy or DnSpy to decompile the assembly, converting the IL offset to a code location, and handling common exceptions that recur in server operation.

The ILSpy interface, shown above, displays the IL code split alongside the decompiled C# source. The operator navigates to the method from the stack trace, finds the IL instruction at the offset displayed in brackets, and reads the corresponding C# code to understand which expression caused the exception.

Documentation source: The debugging technique documented in this article is drawn from the official Smartly Dressed Games modding documentation, which credits the community member DiFFoZ for the original discovery.

Who this article is for

This article is written for Unturned™ dedicated server operators and plugin developers who encounter exceptions in the server process and need to determine the exact code location that caused the failure. Familiarity with the server directory structure, the C# language, and a decompilation tool such as ILSpy or DnSpy is assumed.

What you will learn

• How to locate the IL offset in the Player.log stack trace
• How to identify which assembly contains the crashing method
• How to use ILSpy or DnSpy to decompile the assembly and find the IL offset
• How to switch the decompiler display mode from C# to IL
• How to interpret the IL code at the offset to understand the failure
• How to distinguish between exceptions in the vanilla server code and exceptions in plugin code
• Common server exception patterns and their typical resolutions

Background: the IL offset technique

Unity compiles C# source code into Intermediate Language (IL) assemblies -- the .dll files in the server's Unturned_Data/Managed/ directory. When an exception occurs in a release build, Unity does not have access to the original source files (.cs) and cannot include line numbers in the stack trace. Instead, Unity includes the IL offset -- a hexadecimal address within the method's IL code that indicates which instruction was executing when the exception was thrown.

The IL offset appears in the stack trace inside square brackets. For example, in this stack trace from Player.log:

at SDG.Unturned.ResourceSpawnpoint..ctor (System.Byte newType, System.UInt16 newID,
    System.Guid newGuid, UnityEngine.Vector3 newPoint, System.Boolean newGenerated,
    SDG.Unturned.NetId netId) [0x003db] in [hash]:0
                                                    ^^^^^^^^^
                                                    IL offset

The [0x003db] is the IL offset. The hex value 0x003db corresponds to IL instruction index 0x003db within the ResourceSpawnpoint constructor method. The <08e91a6d9e1d4bd5bf2e982fa4148205>:0 is the assembly identifier hash and a placeholder for the source file path (which is empty in a release build).

The technique works by opening the assembly that contains the crashing method in a decompiler that supports IL display mode, navigating to the method identified in the stack trace, finding the IL instruction at the offset, and reading the corresponding C# code that the decompiler displays alongside the IL.

Finding the exception in the log file

The exception stack trace is written to Player.log, not to the server console output or the regular Server.log file. The Player.log file is located at:

Windows: %USERPROFILE%\AppData\LocalLow\Smartly Dressed Games\Unturned\Player.logLinux: ~/.config/unity3d/Smartly Dressed Games/Unturned/Player.log

The Player.log file contains comprehensive Unity engine logging, including all exceptions thrown by the server process. The stack trace includes the full method chain from the outermost caller to the point of failure, with each level showing the IL offset in brackets.

To locate the relevant exception:

1. Open Player.log in a text editor.
2. Search for "Exception" or the specific exception type (e.g., "NullReferenceException", "IndexOutOfRangeException").
3. Scroll from the match upward to find the stack trace, which starts with the method name and IL offset.
4. Copy the stack trace lines for the methods that belong to the Unturned assembly (methods in the SDG.Unturned namespace or plugin-specific namespaces).

The Client.log file (in the server's Logs/ directory) includes a condensed version of the exception message but does not include the IL offset. Always use Player.log for IL-offset-based debugging.

Identifying the correct assembly

The method name in the stack trace includes the namespace and class name. For example, SDG.Unturned.ResourceSpawnpoint..ctor tells you that the method is the constructor of the ResourceSpawnpoint class in the SDG.Unturned namespace. This class lives in the Assembly-CSharp.dll file, which is the primary game logic assembly.

Common assemblies and their contents:

Assembly	Contents
Assembly-CSharp.dll	Core game logic: items, vehicles, zombies, resources, level loading, player management
Assembly-CSharp-firstpass.dll	Third-party library wrappers and early-load code
UnityEngine.dll	Unity engine runtime types
UnityEngine.CoreModule.dll	Unity engine core module types
Plugin assemblies	Custom code from RocketMod, OpenMod, or other plugin frameworks

For exceptions in the SDG.Unturned namespace, the assembly is almost always Assembly-CSharp.dll. For exceptions in plugin namespaces, the assembly is the plugin's compiled .dll file.

Decompiling the assembly with ILSpy or DnSpy

ILSpy and DnSpy are free .NET decompilers that can display both the decompiled C# code and the raw IL code for any method in an assembly. The workflow is the same for both tools.

Step 1: open the assembly

Launch ILSpy or DnSpy. Open the assembly file that contains the crashing method. For Assembly-CSharp.dll, the path is:

<ServerInstallation>/Unturned_Data/Managed/Assembly-CSharp.dll

Step 2: search for the method

Use the search function (Ctrl+Shift+F in ILSpy, Ctrl+E in DnSpy) to find the method from the stack trace. Enter the method name without the IL offset -- for example, ResourceSpawnpoint..ctor or just ResourceSpawnpoint. The search results show all methods that match the search term.

Step 3: switch to IL display mode

ILSpy shows decompiled C# code by default. To switch to IL display mode:

1. Click on the method in the tree view to select it.
2. Change the display mode dropdown from "C#" to "IL with C#" or "IL" in the toolbar.
3. The display splits into two panes: the left pane shows the IL instructions with their offsets, and the right pane shows the decompiled C# code.

DnSpy offers a similar split-view mode. Select the method and press F11 to toggle between C# and IL views.

Step 4: locate the IL offset

Find the IL instruction at the offset from the stack trace. The IL offsets are displayed as hexadecimal values at the beginning of each instruction line. Scroll to IL_03db (or whatever offset the stack trace showed) and read the instruction at that location.

For 0x003db, the IL instruction would be labeled as IL_03db (the 0x prefix is dropped in the decompiler display). The instruction might be something like:

IL_03db: callvirt instance void [UnityEngine.CoreModule]UnityEngine.Object::set_name(string)

This instruction tells you that the failure occurred while calling the set_name method on a UnityEngine.Object -- which means a null object reference was encountered when trying to set the name property.

Step 5: cross-reference with the C# view

Toggle back to C# view or look at the decompiled C# code that ILSpy displays alongside the IL. The C# code at the corresponding location shows the source logic that produced the failing IL instruction. If the decompiler shows the line number within the decompiled output, you can see exactly which C# expression corresponds to the IL offset.

Common server exceptions and IL offset interpretation

Exception type	Common IL offset patterns	Typical cause
NullReferenceException	IL offset at a callvirt instruction on an object instance	An object was null when a method or property was accessed. Check for uninitialized variables, missing asset references, or removed Workshop content
IndexOutOfRangeException	IL offset at an array access instruction (ldelem, stelem)	An array index exceeded the array bounds. Check for list/array population mismatches or configuration values that specify more items than exist
MissingMethodException	IL offset at a call instruction for a method that does not exist	A plugin references a method that was removed or renamed in the current server version. Update the plugin or check for version mismatches
TypeLoadException	IL offset during static initialization	A type in a loaded assembly cannot be loaded due to missing dependencies or version conflicts
InvalidCastException	IL offset at a castclass or isinst instruction	A type cast failed because the object was not of the expected type. Check for type mismatches in asset references or configuration

Diagnostic table

Symptom	Likely cause	Resolution
NullReferenceException in ResourceSpawnpoint..ctor	A resource spawnpoint references an asset that is not loaded	Check the map's spawn table for missing resource asset GUIDs
IndexOutOfRangeException in ItemManager	The item ID in a spawn table is outside the valid range	Verify all item IDs in spawn tables are within the 0-65535 uint16 range
MissingMethodException after server update	A plugin calls a method that was removed in the new version	Update all plugins to versions compatible with the current server build
Exception in Player equipping handler	A clothing or weapon asset has a corrupted .dat file	Validate all item .dat files in the Workshop content folder
EndOfStreamException in level loading	A level data file is truncated or corrupted	Re-extract the level files from the original source or verify file integrity
StackOverflowException in UseableGun	Infinite recursion in a gun asset's action configuration	Check for circular references in gun action chains

Working with plugin exceptions

Exceptions in plugin code follow the same IL offset technique but the assembly is the plugin's .dll file rather than the vanilla Assembly-CSharp.dll. The plugin's .dll is typically located in the Modules/ directory (for OpenMod plugins) or the Rocket/Plugins/ directory (for RocketMod plugins).

When debugging a plugin exception:

1. Locate the plugin's .dll file using the namespace name from the stack trace.
2. Open the plugin .dll in ILSpy or DnSpy.
3. Search for the method name from the stack trace.
4. Find the IL offset and cross-reference with the decompiled code.

Plugin exceptions are often caused by version mismatches between the plugin and the server. A plugin compiled against a previous server version may call methods that have been renamed, removed, or had their signatures changed.

Preventing common exceptions

Prevention technique	What it prevents
Validate Workshop content GUIDs before adding them to spawn tables	NullReferenceException from missing assets
Test plugins on a staging server before deploying to production	MissingMethodException from version mismatches
Keep all plugins updated to versions compatible with the current server version	Various compatibility exceptions
Run -ValidateAssets periodically to detect corrupted asset files	Asset-loading exceptions
Maintain a staging server that mirrors the production configuration	Prevents deploying untested configurations
Log all exceptions to a centralized monitoring system	Enables early detection of new exception patterns

Exception categories and root cause patterns

Different exception types tend to correspond to different categories of server problems. Recognizing the category from the exception type speeds up the diagnosis.

Exception type	Category	Common root causes
NullReferenceException	Missing reference	Asset not found, uninitialized variable, removed Workshop content, corrupted save data
IndexOutOfRangeException	Data mismatch	Array or list accessed beyond its bounds; spawn table with wrong count, configuration with too many entries
InvalidOperationException	State violation	Operation performed in the wrong state; trying to equip a null item, trying to save before initialization
ArgumentException	Invalid input	A method received an argument outside its valid range; negative damage value, invalid GUID format
MissingMethodException	Version mismatch	A plugin calls a method that was removed or renamed between server versions
TypeLoadException	Assembly conflict	A type cannot be loaded due to missing dependencies or duplicate type definitions across assemblies
FileNotFoundException	Missing file	An asset bundle file, configuration file, or data file referenced by the server does not exist at the expected path
UnauthorizedAccessException	Permission issue	The server process does not have read or write access to a file or directory
OutOfMemoryException	Resource exhaustion	The server has exhausted available memory; too many assets, too many players, or a memory leak
StackOverflowException	Infinite recursion	A method calls itself recursively without a termination condition; typically caused by circular configuration references

Frequently asked questions

Why does the stack trace in Client.log not include the IL offset?

The Client.log file is generated by the game's logging system, which receives a condensed version of the exception message from the Unity engine. The IL offset is stripped before the exception data is forwarded to the game log. The full stack trace with IL offsets is only available in Player.log, which is written directly by the Unity engine before the game's logging system processes the exception.

Why does the server exception stack trace sometimes show only one line?

A single-line stack trace means the exception was thrown and caught within the same method, or the exception occurred in a method that the Unity runtime does not provide call chain information for. This is most common in plugin code that catches and rethrows exceptions without preserving the original stack trace. If you see a single-line stack trace, check the plugin's own logging for additional context.

How do I read an IL offset in hexadecimal notation?

The IL offset is displayed in hexadecimal format. The value 0x003db in hexadecimal equals 987 in decimal. The 0x prefix indicates hexadecimal notation. IL offsets are typically displayed with four or five hexadecimal digits (0x003db), which corresponds to an instruction index within the method's IL code body. The offset does not correspond to a byte offset in the file -- it is an instruction index that the decompiler uses to navigate the IL code.

Can I use the IL offset technique with the Mono interpreter instead of the Unity IL2CPP backend?

Unturned uses the Mono scripting backend, not IL2CPP. The IL offset technique works with Mono because Mono preserves IL metadata in the compiled assemblies. If a future Unturned version switches to IL2CPP, the IL offset format may change and the decompilation approach would need to be reevaluated.

What tools can I use to monitor server exceptions in real time?

Real-time exception monitoring requires a tool that reads the Player.log file as it is written and alerts on new exception entries. Custom scripts using tail -f (Linux) or Get-Content -Wait (PowerShell) can monitor the file and trigger notifications when new exception entries appear. Some server hosting panels include built-in log monitoring that performs the same function.

How do I filter out irrelevant exceptions from the Player.log?

The Player.log contains Unity engine messages at various severity levels in addition to actual exceptions. Not every error-level message in Player.log represents a server problem. Some common non-critical entries include: shader compilation messages, missing audio clip warnings, and asset load timing messages. The 57 Studios recommendation is to search specifically for Exception: (with the colon) to find CLR exceptions, and to ignore Warning: and Error: messages from the Unity engine that do not have an associated exception type.

Can I create a crash dump of the server process for offline analysis?

Yes. On Windows, use Task Manager or ProcDump to create a memory dump of the Unturned.exe process. On Linux, use gdb or createdump to capture a core dump. The dump can be analyzed offline with a debugger (Windbg on Windows, GDB on Linux) or with ILSpy/DnSpy for managed code analysis. Crash dumps are larger than log files but contain the full process state at the time of the exception.

Can I debug server exceptions without ILSpy or DnSpy?

No. The IL offset technique requires a decompiler that can display IL code alongside decompiled C# code. A standard text editor cannot interpret IL offsets. ILSpy and DnSpy are the recommended tools because they are free, open-source, and support the split IL/C# view that makes the technique practical.

Is the IL offset the same across different server versions?

No. The IL offset changes every time the assembly is recompiled, which happens on every server version update. An offset from version 3.25.9.1 is not valid for version 3.25.9.2. Always use the Player.log from the server version where the exception occurred.

How do I find the IL offset in a multi-line stack trace?

Each line of the stack trace has its own IL offset. The bottom-most line (the first method called in the chain) has the offset that corresponds to the exact point of failure. Higher lines show the call chain leading to the failure. For the most precise diagnosis, use the bottom-most offset.

Can I debug exceptions from plugin code that is obfuscated?

Obfuscated plugin assemblies may have method names that are not human-readable (e.g., a.b.c instead of MyPlugin.MyMethod). The IL offset technique still works with obfuscated assemblies -- the method name is less informative, but the IL code at the offset still shows what operation was being performed. Contact the plugin author for a non-obfuscated version if you need clearer debugging.

Can I use the IL offset technique for exceptions that happen during server startup?

Yes, but the stack trace may be truncated because the exception occurs before the logging system is fully initialized. The Player.log file is written by the Unity engine, which initializes before the game's logging system. Startup exceptions are captured in Player.log with full IL offsets.

How do I distinguish between an exception in vanilla code and an exception in a plugin?

Check the namespace in the stack trace. Methods in the SDG.Unturned namespace are vanilla code. Methods in other namespaces (e.g., Rocket.Unturned, OpenMod, or a custom plugin namespace) belong to plugins. If the stack trace starts in a plugin method and calls into vanilla code, the root cause may be in either layer.

What does "in hash:0" mean at the end of each stack trace line?

The <hash>:0 portion is a placeholder that Unity generates for release builds. The hash is an assembly identifier, and the 0 is a placeholder for the source file line number, which is unavailable because the assembly was compiled without debug symbols. In debug builds, this portion shows the source file path and line number (e.g., C:\Builds\Unturned\Assets\Scripts\ResourceSpawnpoint.cs:42).

Can I attach a debugger to a running server process for real-time exception debugging?

Yes, but it requires a debugger that supports Unity process attachment. Visual Studio with the Unity extension can attach to the server process and break on exceptions as they occur. The process name to attach to is Unturned.exe. Attaching a debugger is more powerful than post-mortem IL offset analysis but requires the debugger to be running on the server machine or accessible through remote debugging.

Why does the same exception sometimes show different IL offsets?

A method that has multiple code paths may throw the same exception type from different instructions. For example, a NullReferenceException can occur at multiple points in a method if different object references are null in different invocations. The IL offset tells you which specific instruction failed, which helps identify which reference was null in that particular invocation.

How do I debug exceptions that happen only occasionally?

Intermittent exceptions are the hardest to debug. The recommended approach is to enable verbose logging for the relevant system, collect multiple Player.log files from different occurrences, and look for patterns in the IL offsets. If the offset is always the same, the failure is deterministic (same condition every time). If the offset varies, the failure depends on runtime state that differs between invocations.

What if the ILSpy or DnSpy search cannot find the method from the stack trace?

The method may be in a different assembly than expected. Verify the assembly name by checking the namespace and class. If the method is in the SDG.Unturned namespace but the search finds nothing, the method may have been inlined by the compiler or may be in a nested class. Search for the class name first, then navigate to the method manually through the tree view.

What if the IL offset points to a line in the middle of a C# expression?

The IL offset corresponds to a single IL instruction, which may represent a sub-operation within a larger C# expression. For example, in the expression obj.Method(GetValue()), the IL for calling GetValue() has a different offset than the IL for calling Method(). Inspect the surrounding IL instructions to understand the full expression context.

Is there a way to get source-level line numbers without the IL offset technique?

Running the server with debug symbols (.pdb files) present in the Managed/ directory produces stack traces with file paths and line numbers. However, the official Unturned dedicated server release does not include .pdb files. The IL offset technique is the only reliable method for release-build debugging.

The Player.log anatomy for exception debugging

Understanding the full structure of a Player.log exception entry helps operators extract the right information without parsing irrelevant log lines.

A complete exception entry in Player.log has three parts:

[Timestamp] [Exception type: Message]
    Stack trace line 1 with IL offset
    Stack trace line 2 with IL offset
    ...
    Stack trace line N with IL offset
[Timestamp] [Context information]

The timestamp shows when the exception occurred. The exception type is the CLR exception type (NullReferenceException, InvalidOperationException, etc.) followed by the exception message that the throwing code provided. Each stack trace line shows one method in the call chain, with the IL offset in square brackets.

The stack trace reads from top to bottom: the first line is the method that threw the exception, and each subsequent line is the caller of the previous line. The bottom-most line is the entry point that started the chain of calls leading to the exception.

For example:

[13:45:22] [NullReferenceException: Object reference not set to an instance of an object]
  at SDG.Unturned.ItemManager.getItem (System.UInt32 id) [0x0012a] in hash:0
  at SDG.Unturned.UseableGun.Shoot () [0x0045b] in hash:0
  at SDG.Unturned.PlayerLife.Simulate (SDG.Unturned.uint32 simulation) [0x00891] in hash:0

The bottom-most line (PlayerLife.Simulate) called UseableGun.Shoot, which called ItemManager.getItem, which threw the exception at IL offset 0x0012a. The operator would decompile ItemManager.getItem and look at IL offset 0x0012a to find the null reference.

Full worked debugging example

This worked example traces a real debugging session from exception to resolution.

Step 1: the exception occurs

The server crashes with the following entry in Player.log:

[18:22:45] [NullReferenceException: Object reference not set to an instance of an object]
  at SDG.Unturned.ResourceSpawnpoint..ctor (System.Byte newType, System.UInt16 newID,
      System.Guid newGuid, UnityEngine.Vector3 newPoint, System.Boolean newGenerated,
      SDG.Unturned.NetId netId) [0x003db] in [hash]:0
  at SDG.Unturned.ResourceManager.getResourceSpawnpoint (System.Byte type,
      System.UInt16 id) [0x0071c] in hash:0
  at SDG.Unturned.Level.loadResources () [0x00a33] in hash:0

Step 2: extract the key information

The exception is a NullReferenceException. The crashing method is ResourceSpawnpoint..ctor (the constructor) in the SDG.Unturned namespace. The IL offset is 0x003db. The assembly is Assembly-CSharp.dll.

Step 3: open the assembly in ILSpy

The operator opens Assembly-CSharp.dll from the server's Unturned_Data/Managed/ directory in ILSpy.

Step 4: search for the method

The operator searches for ResourceSpawnpoint and selects the constructor method (.ctor).

Step 5: switch to IL display mode

The operator changes the display mode from "C#" to "IL with C#". The IL instructions appear in the left pane with their offsets.

Step 6: find the IL instruction at offset 0x003db

The operator scrolls to IL_03db and sees:

IL_03db: callvirt instance void [UnityEngine.CoreModule]UnityEngine.Object::set_name(string)

The callvirt instruction on set_name means the code is trying to call the set_name method on an object instance, but the instance is null.

Step 7: cross-reference with C# code

The operator switches back to C# view and finds the corresponding line:

spawnpoint.gameObject.name = "Resource_" + id;

The spawnpoint variable is null at this point. The constructor received id from the caller but the spawnpoint game object was not created before this line executed.

Step 8: trace back to the caller

The operator switches to the ResourceManager.getResourceSpawnpoint method and finds the call to the constructor. The operator sees that getResourceSpawnpoint is called with resource IDs from the level data, and one of those resource IDs references an asset that does not exist in the currently loaded asset set. When the constructor tries to create a spawnpoint for a missing resource, the game object creation fails, leaving spawnpoint null.

Step 9: apply the fix

The operator identifies the resource ID from the level data that references a non-existent asset (perhaps a Workshop resource asset that was removed or a map that references a custom resource that is no longer loaded). The operator either restores the missing asset, removes the spawnpoint from the level, or updates the level to use a valid resource reference.

Best practices

• Always check Player.log for exceptions before Client.log. The Player.log contains the IL offsets that make debugging possible.
• Keep ILSpy or DnSpy installed on the server management workstation so that it is available when an exception occurs.
• Record the IL offset and the method name from every exception that you diagnose. Over time, these records build into a reference of common exception patterns for your specific server configuration.
• Search the official SDG documentation and community forums for an IL offset before spending time decompiling. The same exception may have been reported and resolved before.
• When reporting an exception to a plugin author, include the full stack trace from Player.log (including IL offsets) and the server version. The author needs this information to diagnose the issue.

Exception prevention through server configuration

Many common server exceptions can be prevented through careful configuration management rather than requiring post-mortem debugging.

Configuration validation before deployment

Validate every configuration file change before deploying it to a production server. A missing comma in Config.json, a removed asset GUID in a spawn table, or a misspelled field name in a .dat file can cause exceptions that take hours to diagnose. Use JSON validators for Config.json, verify asset GUIDs against the Workshop item list, and test configuration changes on a staging server first.

Workshop content management

The most common source of NullReferenceException in production servers is Workshop content that has been removed, updated destructively, or has version incompatibilities. Maintain a manifest of all Workshop items that the server depends on, pin specific versions where possible, and test Workshop content updates on a staging server before applying them to production.

Plugin compatibility tracking

Track the compatibility relationship between each plugin and the server version. When the server updates, compare the plugin versions against the known-compatible version list. A MissingMethodException during server startup almost always indicates a plugin that has not been updated for the current server version.

Memory management

OutOfMemoryException on a dedicated server is typically caused by excessive asset loading, not by player activity. Limit the number of Workshop items loaded, use the -NoDeferAssets flag to control asset loading behavior, and monitor the server process's memory usage over time to establish a baseline.

Appendix A: IL offset debugging quick reference

Step	Action	Tool
1	Locate the exception in Player.log	Text editor
2	Extract the method name and IL offset from the stack trace	Text editor
3	Identify the assembly containing the method	Based on namespace
4	Open the assembly in a decompiler	ILSpy or DnSpy
5	Search for the method name	ILSpy search (Ctrl+Shift+F)
6	Switch to IL display mode	ILSpy dropdown or DnSpy F11
7	Find the IL instruction at the offset	Scroll to IL_XXXX
8	Read the corresponding C# code	Split pane view

Appendix B: Stack trace format reference

Stack trace component	Example	Purpose
Method signature	SDG.Unturned.ResourceSpawnpoint..ctor	Full namespace, class, and method name with parameter types
IL offset	[0x003db]	Hexadecimal offset within the method's IL code
Assembly hash	<08e91a6d9e1d4bd5bf2e982fa4148205>	Identifier for the compiled assembly containing the method
Source placeholder	:0	Placeholder for source file path and line number (empty in release builds)
Exception type	NullReferenceException	CLR exception type indicating the kind of failure
Exception message	Object reference not set to an instance of an object	Human-readable description of the failure

Appendix C: Decompiler installation and setup

Tool	Download	Setup	Notes
ILSpy	GitHub releases (icsharpcode/ILSpy)	Portable, no installation required	Open assembly, search method, switch to IL with C# mode
DnSpy	GitHub releases (dnSpy/dnSpy)	Portable, no installation required	Open assembly, search method, press F11 for IL mode

Both tools are free, open-source, and do not require administrator privileges to run. Keep a copy on the server management workstation for immediate access when an exception occurs.

Appendix D: External references

• Smartly Dressed Games modding documentation -- official reference for the IL offset debugging technique, credited to DiFFoZ.
• ILSpy -- free .NET decompiler with IL/C# split view.
• DnSpy -- free .NET debugger and decompiler with IL/C# split view.
• Command IO Reference -- the previous article; covers the command input-output system.
• Mod Load Order and Conflict Resolution -- the next article; covers mod conflict debugging.

Document history

Version	Date	Author	Notes
1.0	2026-07-26	57 Studios	Initial publication. Complete reference for server-side IL offset debugging, decompiler workflow, common exception patterns, and diagnostic guidance.

Authoring checklist

• [ ] ILSpy or DnSpy is installed on the server management workstation
• [ ] The Player.log file location is documented in the server operations guide
• [ ] Common exception patterns for this server's configuration are documented
• [ ] Plugin authors have been informed about the need to provide debug-compatible builds for their plugins
• [ ] A staging server is available for testing plugin updates before production deployment

Appendix E: Exception type severity classification

Severity	Exception types	Response
Critical	NullReferenceException, StackOverflowException, OutOfMemoryException, TypeLoadException	Immediate investigation required. These exceptions can crash the server or cause data corruption.
High	MissingMethodException, FileNotFoundException, UnauthorizedAccessException	Investigate within 24 hours. These exceptions prevent specific features from working.
Medium	IndexOutOfRangeException, ArgumentException, InvalidCastException	Investigate within the week. These exceptions affect specific gameplay scenarios.
Low	InvalidOperationException in non-critical paths	Log and monitor. These exceptions recover without operator intervention.

Appendix F: Common Player.log search patterns

Search term	What it finds	When to use
Exception:	All CLR exceptions with stack traces	During initial investigation
NullReferenceException	Null reference failures specifically	When an object reference is null
MissingMethodException	Version mismatch failures	After a server update
IndexOutOfRangeException	Array or list access failures	When configuration data may be out of range
StackTrace	Beginning of a stack trace entry	When scanning for exception context
[0x	Any IL offset reference	When extracting IL offsets for decompilation

Cross-references

• Command IO Reference -- the previous article; covers the command input-output system.
• Mod Load Order and Conflict Resolution -- the next article; covers mod conflict resolution that may generate load-time exceptions.
• Server Config Files: Commands.dat, Players.dat, Config.json -- server configuration file reference.
• Smartly Dressed Games modding documentation -- official documentation for the debugging technique.
• Unturned on Steam -- Unturned™ store page.