In Part 1 of this series, I walked through debugging JavaScript in Dynamics 365 CE. Now, let's dive into Plugins—the backbone of server-side customisation.
If you’ve moved beyond out-of-the-box features, you've likely written or dealt with plugins. Powerful as they are, debugging them can feel like detective work. Here’s how I tackle plugin debugging in my DEV environments:
1) Start with the error message — but don’t stop there
User-facing errors are often vague—think “An error has occurred”—and not very helpful.
Enable plugin trace logs in CE: Settings → Administration → System Settings → Customization → Enable logging to plug-in trace log, then reproduce the issue.
The trace log typically gives you:
The plugin step that fired
The exact exception (e.g., null reference, permissions)
Stack trace to trace back to the failing line
2) Two ways to debug in DEV
a) Plugin Registration Tool (PRT) Profiler
Use this when you want to step through your code in Visual Studio.
Steps (from Microsoft’s official tutorial):
In PRT, click Install Profiler.
Right-click the plugin step (e.g., Create of Account) → Start Profiling.
Reproduce the action in CE (e.g., create an account) to capture the execution profile.
In PRT, click Debug, pick the captured profile, and replay execution.
In Visual Studio: set breakpoints, attach to PluginRegistration.exe, then Start Execution and step through.
Best for: deep inspection—variable states, execution path, runtime payloads.
Important: only use in DEV/Sandbox, never in Production.
b) Debug directly with plugin trace logs (no PRT)
You don’t always need a full debugger—trace logs are often enough.
What I do:
Sprinkle ITracingService.Trace() calls as breadcrumbs across logic branches.
Temporarily set logging level to All in DEV.
Reproduce the issue, then read the Plugin Trace Logs to follow execution flow, values, and errors.
Best for:
Quick checks on logic flow
Spotting nulls/unexpected inputs
Comparing multiple plugins firing on the same message
Tip: Tracing increases storage—disable or lower the level when finished.
3) Isolate the step
When behaviour is odd:
Check the execution order—another plugin may be changing context before yours runs.
In DEV, selectively disable unrelated steps to isolate the culprit (never do this in Production).
4) Use tracing inside your code
Simple, effective tracing template:
public void Execute(IServiceProvider serviceProvider)
{
var context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));
var tracing = (ITracingService)serviceProvider.GetService(typeof(ITracingService));
try
{
tracing.Trace("Plugin started. Entity: {0}", context.PrimaryEntityName);
tracing.Trace("Message: {0} | Stage: {1} | Mode: {2}", context.MessageName, context.Stage, context.Mode);
var hasTarget = context.InputParameters.Contains("Target");
tracing.Trace("Has Target: {0}", hasTarget);
if (hasTarget && context.InputParameters["Target"] is Entity target)
{
tracing.Trace("Target LogicalName: {0} | Id: {1}", target.LogicalName, target.Id);
// ... your logic
}
// ... more logic and trace breadcrumbs
}
catch (Exception ex)
{
tracing.Trace("Exception: {0}", ex);
throw;
}
}
These breadcrumbs land in the Plugin Trace Logs and make replaying the story much easier.
5) Check security & permissions
Quiet failures often come from permissions:
Confirm if the step runs as Calling user or System user.
Missing privileges = confusing errors (or silent failures against related records).
6) Don’t forget external dependencies
When talking to anything outside Dataverse (APIs, Service Bus, custom assemblies), verify:
Assembly versions and dependency binding
Connection strings / app registrations / secrets
Network and firewall constraints
Real-world example
I once had invoices not syncing with FinOps:
The trace showed a NullReferenceException. It revealed a key attribute on the Target was missing. Another plugin (lower execution order) was wiping that field.
Fix: reorder the steps and add a defensive null check.
Key takeaways
Enable trace logs early—don’t wait for production issues.
Pick the right tool for the moment:
PRT Profiler for Visual Studio step-through
Trace logs for faster, lighter iterations
Trace liberally to leave clear breadcrumbs.
Validate step configuration—execution order and user context matter.
Debugging is detective work: follow the clues to the root cause.
Part 3 will cover debugging Power Automate flows inside CE—especially those silent failures and pesky retries.
Top comments (0)