✏️ Explanatory Question

How do you debug X++ code in Dynamics 365 Finance & Operations? Explain breakpoints (including conditional), how to attach the debugger, the role of the Infolog and Debug::assert, and best practices for diagnosing hard-to-reproduce issues.

👁 1 Views
📘 Detailed Answer
🟢 Easy
← Previous Describe the Application Lifecycle Management (ALM) process in Dynamics 365 Finance & Operations. What is the role of LCS, the build pipeline, a deployable package, and how does code flow through the DEV → BUILD → UAT → PROD environments?
💡

Answer with Explanation

D365 F&O • X++ INTERVIEW

Debugging Techniques in Dynamics 365 Finance & Operations

Question 55 — Breakpoints, conditional/cross-company debugging, Infolog, and diagnostic best practices.

Interview Question

How do you debug X++ code in Dynamics 365 Finance & Operations? Explain breakpoints (including conditional), how to attach the debugger, the role of the Infolog and Debug::assert, and best practices for diagnosing hard-to-reproduce issues.

Model Answer (Short)

You debug X++ directly in Visual Studio by setting breakpoints and attaching to the process (typically IIS / w3wp.exe for the web client, or the batch process for batch jobs). Visual Studio supports conditional breakpoints, watch/locals windows, call stack, and step in/over/out. For quick tracing without breakpoints you can write to the Infolog (info, warning, error) or use Debug::assert() to halt when a condition fails. For hard-to-reproduce or performance issues you use Trace Parser, the database/execution plan, and the batch job history. Best practice is to reproduce in a DEV/Tier-1 box, use conditional breakpoints to avoid stopping on every iteration, and remove temporary Infolog/debug code before check-in.

Debugging Approaches

Breakpoints & attaching

  • Set a breakpoint in the X++ method, then Attach to Process.
  • Attach to w3wp.exe / iisexpress for the interactive web client.
  • Attach to the batch process (Batch.exe / the AOS batch service) for batch jobs.
  • Use step in / over / out, the call stack, and watch/locals windows.

Conditional breakpoints

  • Break only when a condition is true (e.g. a specific SalesId).
  • Avoids stopping on every loop iteration in high-volume code.
  • Great for isolating a single problem record.

Infolog & Debug::assert

  • Write to the Infolog with info, warning, error for lightweight tracing.
  • Debug::assert(condition) halts execution when the condition is false (dev only).
  • Use strFmt to include variable values in trace messages.
  • Remove temporary Infolog/assert code before check-in.

For hard-to-reproduce / performance issues

  • Use Trace Parser for slow code / SQL and call counts.
  • Inspect the SQL execution plan and Activity Monitor.
  • Review the batch job history and logs for background failures.
  • Reproduce in a Tier-1 DEV box with representative data.
GOLDEN RULE
Reproduce in DEV  •  Conditional breakpoints  •  Remove debug code before check-in

Prerequisites (Rule 5)

  • Visual Studio with the Dynamics 365 developer tools, run as administrator.
  • A Tier-1 DEV environment where you can attach the debugger.
  • The relevant model in your solution (symbols loaded).
  • Representative test data to reproduce the issue.

Code Example — Infolog tracing with values

public void processLine(SalesLine _salesLine)
{
    // Lightweight trace — remove before check-in
    info(strFmt("Processing SalesId %1, Line %2, Amount %3",
                _salesLine.SalesId,
                _salesLine.LineNum,
                _salesLine.LineAmount));

    // ... business logic ...
}

Using Debug::assert for a dev-time invariant

public void applyDiscount(SalesLine _salesLine, Percent _discount)
{
    // Halt in the debugger if an invariant is violated (dev only)
    Debug::assert(_discount >= 0 && _discount <= 100);

    _salesLine.LineAmount = _salesLine.LineAmount * (1 - _discount / 100);
}

Conditional breakpoint scenario

while select salesLine
{
    // Set a CONDITIONAL breakpoint here in Visual Studio, e.g.:
    //   Condition:  salesLine.SalesId == 'SO-0001'
    // so execution only halts for the problem record.
    this.processLine(salesLine);
}

Debugging Tool Selection

Scenario Best approach
Step through interactive UI logic Breakpoint + attach to w3wp.exe
Debug a batch job Breakpoint + attach to the batch process
Isolate one bad record in a loop Conditional breakpoint
Lightweight value tracing Infolog (info/warning/error)
Slow code / SQL Trace Parser + execution plan

Points the interviewer wants to hear

  • Debug in Visual Studio with breakpoints and Attach to Process (w3wp / batch).
  • Use conditional breakpoints to isolate a specific record.
  • Infolog and Debug::assert give lightweight tracing.
  • For performance/repro issues use Trace Parser and the execution plan.
  • Remove temporary debug/Infolog code before check-in.

Likely Follow-up Questions

  • Which process do you attach to when debugging the web client vs. a batch job?
  • Why use a conditional breakpoint in a high-volume loop?
  • What is the difference between info() tracing and Debug::assert()?
  • How would you debug an issue that only happens in a batch on a Tier-2 environment?

Key Takeaway

Debug X++ in Visual Studio using breakpoints (attach to w3wp/batch), conditional breakpoints to isolate records, and the Infolog / Debug::assert for quick tracing. Escalate to Trace Parser and the execution plan for performance issues — and always remove debug code before check-in.

D365 F&O Interview Series — Question 55 of many
← Previous Describe the Application Lifecycle Management (ALM) process in Dynamics 365 Finance & Operations. What is the role of LCS, the build pipeline, a deployable package, and how does code flow through the DEV → BUILD → UAT → PROD environments?