icsharpcode/ILSpy · error · DecompilerException

Error decompiling @{MetadataTokens.GetToken(entity.MetadataT

Error message

Error decompiling @{MetadataTokens.GetToken(entity.MetadataToken):X8} {entity.FullName}

What it means

DecompilerException wrapping any failure inside DoDecompile(ITypeDefinition). The catch re-throws non-cancellation, non-DecompilerException errors as DecompilerException(module, typeDef, inner) whose default message is 'Error decompiling @<token> <fullname>'. The InnerException is the real cause; this wrapper localizes the failure to one type so a batch decompile can continue with the rest.

Source

Thrown at ICSharpCode.Decompiler/CSharp/CSharpDecompiler.cs:1921

								}
							}
							break;
						default:
							throw new ArgumentOutOfRangeException();
					}
					foreach (var item in typeDecl.Members)
					{
						if (item is not EnumMemberDeclaration)
						{
							item.AddLeadingTrivia(new Comment(" error: nested types are not permitted in C#."));
						}
					}
				}
				return typeDecl;
			}
			catch (Exception innerException) when (!(innerException is OperationCanceledException || innerException is DecompilerException))
			{
				throw new DecompilerException(module, typeDef, innerException);
			}
			finally
			{
				DecompilerEventSource.Log.DecompileTypeStop(typeDef);
			}

			// MemberIsHidden identifies event backing fields from the metadata name association
			// alone. When the event's accessors turn out not to be compiler-generated, the event
			// is decompiled with explicit accessors and no field-like declaration takes the
			// field's place, so the field must stay in the output even if no decompiled body
			// references it (referenced hidden members are re-added via the work list).
			bool IsBackingFieldOfNonAutomaticEvent(IEntity entity)
			{
				if (entity is not IField field || !settings.AutomaticEvents)
					return false;
				if (!module.MetadataFile.PropertyAndEventBackingFieldLookup.IsEventBackingField((FieldDefinitionHandle)field.MetadataToken, out var eventHandle))
					return false;
				if (AutoEventDecompiler.IsAutomaticEvent(typeSystem, module.GetDefinition(eventHandle), decompileRun, CancellationToken, out _))

View on GitHub (pinned to 60c08fcb74)

Solutions

Catch DecompilerException and inspect InnerException / StackTrace for the root cause.
Report the InnerException type and the failing type token as an ILSpy issue if the assembly is valid.
Reproduce on a single type to isolate it: decompiler.Decompile(typeHandle).
If the assembly is obfuscated, try deobfuscation or the IL disassembler (ReflectionDisassembler) instead.

Defensive patterns

Strategy: try-catch

Try / catch

try {
    var tree = decompiler.Decompile(typeHandle);
} catch (DecompilerException ex) {
    logger.Error(ex, "Failed to decompile {Entity}: {Inner}", ex.DecompiledEntity?.FullName, ex.InnerException?.Message);
    // continue with remaining types; the failure is scoped to this one entity
}

Prevention

Decompile one entity at a time in a loop and isolate failures.
Keep assemblies and ILSpy versions current; many inner exceptions are fixed bugs.

When it happens

Trigger: Any internal exception (bad IL, unsupported construct, transform bug, NullReferenceException on obfuscated metadata) thrown while decompiling a single type, when it is not already an OperationCanceledException or DecompilerException.

Common situations: Obfuscated/encrypted assemblies; assemblies produced by F#, ILASM, or older/preview compilers; types with malformed metadata; decompiler version gaps on new language features.

Related errors

AI-assisted analysis of icsharpcode/ILSpy@60c08fcb74 (2026-08-13). Data as JSON: /api/errors/5b7ac2ddaafc5caa. Report an issue: GitHub.