A plugin throws in production. You have a stack trace, but you cannot attach a debugger to a customer environment. The Plugin Profiler is built for exactly this. Most teams forget it exists.
What it does
The Plugin Profiler is a step that wraps your plugin and serializes the execution context (inputs, target entity, secure config, pre/post images) to either a Dataverse record or a downloaded file. You then replay that exact context locally in Visual Studio with breakpoints. No remote debug, no production access, no synthetic test data.
Install the profiler
In the Plugin Registration Tool (PRT, available via XrmToolBox or the standalone download), connect to your environment, select the plugin step you want to profile, and click “Start Profiling.” Choose “Persist to Entity” for repeatable replay or “Exception” mode for fire-and-forget.
The tool registers a wrapping step that intercepts the execution context. Your real plugin still runs; the profiler is non-invasive.
Capture a real failure
For “Exception” mode, the next time the plugin throws in production, the profiler writes the context to the user’s screen as an XML download (for user-triggered ops) or to the plugintracelog (for async/system). For “Persist” mode, every execution within a configured time window is captured to the pluginprofile entity.
Grab the XML. It contains everything needed to reconstruct the call.
Replay locally
In PRT, click “Replay Plugin Execution” and provide:
- The captured XML profile
- The path to your plugin assembly DLL (built in Debug)
- Optional: attach to Visual Studio process for breakpoint debugging
PRT runs your plugin in-process locally with the captured context. Breakpoints fire. Step through the failing logic with real production data. Fix it. Build. Replay again. Iterate until green.
What about secure configuration
Secure config is encrypted in production and not included in the profile XML by default. For local replay, manually inject the secure config string in PRT’s replay dialog. Keep production secrets out of source control; use a local dev secrets file with the same shape but dev values.
Limitations
The profiler does not capture downstream service calls. If your plugin calls an external API, you will get a real network call during replay. Use Polly or HttpClientFactory with a swappable handler so you can mock external calls in dev.
It also cannot profile real-time workflows or modern Power Automate flows. For flow debugging, use the run history and the Test feature with a captured trigger payload.
When to leave it on
Production profiling adds overhead, roughly 10 to 50 ms per invocation depending on payload size. Leave “Exception” mode on for plugins that fail rarely but mysteriously. Leave “Persist” mode on only during a focused incident, then remove the wrapping step.
Pair with a synthetic test harness
Once you have captured a tricky context, save the XML in your test repo as a fixture. Build an xUnit test that loads the fixture and exercises the plugin via a fake IOrganizationService. The next regression that breaks the same path catches it in CI before it reaches production.
What to do this week: install PRT, register the profiler in Exception mode against your two most failure-prone plugin steps, and add a “captured-context” fixtures folder to your test project.
