Diagnosing a protected .NET build in production: logs, PDBs and stack traces

You hardened the build the way you were supposed to. Renaming, string encryption, control-flow obfuscation, a virtualized licensing path — the binary that ships reads like noise in a decompiler. Then a support ticket lands: the app crashed on a customer's machine, here is the stack trace, and every frame says a.b(c). You cannot attach a debugger to their box, you would not be able to step through the virtualized method if you could, and the PDB that would make the trace readable is the one thing you deliberately did not ship. Protection worked — and now diagnosis is the hard part.

This is the ops reality obfuscation guides skip. A protected build is not supposed to be a black box to you; it is supposed to be one to an attacker. The whole game is keeping it diagnosable on your side without undoing the protection on theirs. This post is the playbook: what to do about PDBs, how to read the traces, why diagnosis goes logging-first, and how to keep your signals useful without leaking what you just hid. It all applies to a build protected with Nebula.NET.

Why you usually should not ship full PDBs

The instinct, the first time an unreadable trace arrives, is to ship the PDBs so the names and line numbers come back. Resist it. A pre-obfuscation portable PDB is a near-complete inverse of renaming: it maps every IL offset to your original method, type, parameter and local-variable names, plus your source file paths. Drop it next to a protected assembly and an attacker with a decompiler gets back most of what renaming removed, for free. A shipped original PDB is, functionally, a shipped rename map.

The trade-off is real, though, so be precise about it. A .NET stack trace only carries line numbers when a matching PDB is present at runtime. Ship nothing and your field traces give you method identity (in obfuscated names) and call order, but no lines. There are three sane positions:

• Ship no symbols (the default). Smallest surface, zero leak. You rely on the rename map plus the method/frame identity in the trace. You lose line numbers in the field.
• Ship a PDB that matches the obfuscated output. The names in it are already the obfuscated ones, so it re-exposes nothing original, yet it restores IL-offset-to-line mapping. Combined with your archived rename map, you recover real names and lines server-side. Only do this with a PDB generated against the protected assembly — never the original.
• Keep all symbols archived, ship nothing. Treat PDBs like the rename map: a per-build artifact in your artifact store, keyed by version and module, retrieved only when a crash report comes in. This is the position most teams should default to.

Whichever you pick, the rule is the same one as for the rename map: the dictionary that turns the shipped binary back into your source stays on your side.

Mapping a production trace back to real methods

The good news buried in that wall of a.b(c) is that nothing is lost. The exception type, the message, the call order and — if you kept symbols — the line numbers are all genuine; the trace faithfully reports the names that are actually in the binary, which are the obfuscated ones. What you need is the rename map Nebula emitted for that exact build: the .symbols.json file written next to each protected assembly, recording original → obfuscated for every renamed symbol along with its metadata token. The full mechanics of reading a trace back frame by frame — including why compiler-generated closure frames survive and how signature matching works — are in reading obfuscated stack traces.

On your side, nebula deobfuscate --map MyApp-2.3.0.symbols.json turns the incoming trace into real names. Wire that into wherever crash reports land so symbolication happens automatically on intake; your dashboards then show Billing.InvoiceService.Charge and the user never sees — and never needs — a map.

The thing that makes this sustainable across releases is seeding. By default every run renames from scratch, so Charge is a.b.c in 2.3.0 and q.f.d in 2.3.1, and each archived map decodes exactly one build. Point seedMapFile at the previous release's map and unchanged methods keep the obfuscated names they already had, so one archived map decodes a whole release series and you start to recognise a recurring crash by its obfuscated frame before you even decode it. Why that is an operational win and not a security weakening is covered in keeping obfuscated names stable with a seed map. Keep a version-stamped copy of every build's map; it is what decodes that build's traces forever.

Design for logging-first diagnosis

Here is the shift obfuscation forces, and the one most teams underestimate: you cannot step through a protected build, so you have to design it to explain itself. Control-flow obfuscation flattens a method into a state machine driven by a switch, and code virtualization replaces a method's IL with bytecode for a small embedded VM. In both cases there is nothing a debugger can single-step in any way that corresponds to your source. The field diagnosis you get is the diagnosis you logged.

So treat structured logging as the primary instrument, not a fallback. In practice:

• Log at decision points and boundaries. Every place the code branches on customer input, external state or configuration is a place a log line earns its keep, because you will never watch that branch execute live.
• Carry correlation IDs through a request. When you cannot step across a call chain, a shared request/batch ID is what reconstructs the path a failing operation took through methods you can no longer walk.
• Make the first and last line of a risky operation observable. "Started recalculation for batch 4821" / "failed: currency mismatch" turns an opaque virtualized routine into something you can reason about from the outside.

None of this fights the obfuscation. Logging runs your own code emitting your own messages; it is entirely orthogonal to how the IL is protected.

Keep messages and telemetry useful without leaking internals

The discipline that makes logging-first safe is logging behaviour, not structure. A good diagnostic message describes what the software was trying to do and why it stopped — "invoice recalculation failed for batch 4821, reason: currency mismatch" — and that leaks nothing an attacker can turn into architecture. A careless one dumps internal type names, SQL text, config values or full object graphs, and now your diagnostic aid doubles as a reverse-engineering crib sheet on the user's own disk.

Be clear-eyed about what string encryption does and does not do here. It keeps your literals out of the static binary, so grepping the file finds nothing — see string encryption in .NET. But encrypted strings are decrypted in memory at the moment they are used, which is exactly how a message you deliberately log still logs in cleartext. That is the point: encryption protects the literals you did not intend to reveal; it is not a safety net for a message you should not have logged. Curate the message, do not rely on the cipher.

For the one signal you genuinely want from the field — "is a shipped build being attacked?" — there is a sanctioned channel that carries no internals at all. Nebula's report-home / tamper telemetry (tamperReportUrl, a Pro feature) POSTs a minimal event like {"event":"antiTamper"} to an endpoint you run when a runtime guard trips. Only the event name leaves the machine — no source, no assembly bytes, no user data — so it sharpens your field visibility without widening your exposure.

A diagnostics feature flag

You do not want verbose, correlation-heavy diagnostics on by default in production — it is noise, and more logging is more surface. The clean pattern is a diagnostics feature flag: a single switch, read from an environment variable or your config at startup, that raises log verbosity and turns on the extra decision-point and boundary logging only when you ask for it.

// Read once at startup; off unless a support engineer turns it on.
static readonly bool Diagnostics =
    Environment.GetEnvironmentVariable("MYAPP_DIAGNOSTICS") == "1";

void Recalculate(Batch batch)
{
    if (Diagnostics)
        _log.Info("recalc start batch={BatchId} currency={Currency}",
                  batch.Id, batch.Currency);
    // ... real work, inside the virtualized/obfuscated method ...
}

This is app-level code, untouched by obfuscation, so the flag ships in every build and costs nothing when off. When a hard-to-reproduce ticket comes in, you walk the customer through setting one environment variable, collect a rich run, and switch it back off — all without a special build, a debugger or a shipped PDB. Because the flag only adds log volume, it never changes behaviour and never weakens protection.

What each protection does to debuggability

Pulling it together, here is the honest accounting of what each transform costs you in diagnosis and how you pay it back:

• Renaming — frames and symbols read as a, b, c. Fully recoverable: keep the per-build .symbols.json, seed it forward, and symbolicate server-side. Zero diagnosis loss once the map pipeline exists.
• String encryption — literals vanish from the static binary but are decrypted at runtime, so anything you deliberately log still logs in cleartext. No diagnosis loss; just curate your messages.
• Control-flow obfuscation — the method becomes a flattened state machine. You lose meaningful single-stepping; you pay it back with logging at decision points.
• Code virtualization (a Pro feature) — the method's IL becomes VM bytecode; there is nothing to step at all. Same answer, harder: diagnosis of virtualized paths is entirely logging- and message-driven, which is why you reserve virtualization for your most sensitive methods and instrument their boundaries well.

The through-line is the same one that runs through the rename map: protection removes information from the shipped binary, and the discipline is keeping that information on your side instead of giving it up. Keep your PDBs and maps archived, symbolicate on intake, design the code to explain itself through logs, and curate what those logs and messages say. Do that and a fully protected build stays as diagnosable to you as it is opaque to everyone else. Download Nebula.NET free and build the map-and-log pipeline before your first protected release ships, not after the first crash report arrives.