Performance Troubleshooting Tools

Overview

Tool Summaries

1) Performance Profiler (in-client) for Performance Analysis

What it is A built-in Business Central page that records a snapshot of a slow process and shows where time was spent across apps, objects, and methods.

Microsoft Learn: https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/performance-profiler-overview

When to use it

• A process is slow, but the root cause is unclear.
• You need to determine whether most of the time is spent in your app, Microsoft apps, or third-party extensions.
• You need repeatable before-and-after comparisons for a code or configuration change.

Typical value A prioritized hotspot list at the app, application object, and call-tree levels.

Recommended workflow

1. Open Performance Profiler through Tell Me and leave it open in a separate window.
2. Navigate to the business process to investigate.
3. Start the recording immediately before the slow action and stop it immediately afterward.
4. Review Active Apps to identify the app or publisher with the largest share of the time.
5. Enable Show technical information and inspect Time Spent by Application Object and the Call Tree, using Self Time and Total Time.
6. Share or download the .alcpuprofile snapshot for further analysis.

Interpretation notes

• Self Time is the cost inside the method itself.
• Total Time also includes called methods.
• High Total Time with low Self Time often indicates a deeper bottleneck.

2) Profiler Schedules

Decision rule

• Use the Performance Profiler (in-client) when the issue is reproducible and can be recorded around a specific slow action.
• Use Profiler Schedules when the issue is intermittent, occurs outside business hours, or involves background tasks or web service calls.
• Use both where possible: first to identify hotspots, then to validate them under realistic workload periods.

What it is A schedule on the Profiler Schedules page that records matching activities for a selected user and time period, then creates individual profiles for later analysis.

Microsoft Learn: https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/scheduled-performance-profiler-overview

When to use it

• You need to capture intermittent or out-of-hours issues.
• You need to profile background tasks, job queues, or web service calls.
• You need traces for a user workflow over a longer period.

Typical value A reproducible set of activity profiles that can be sorted by metrics and then analyzed in detail with the Performance Profiler.

Recommended workflow

1. Open Profiler Schedules and create a new schedule.
2. Configure the user, activity type, and start and end times.
3. Set the advanced options: Sampling Frequency controls accuracy, and Activity Duration Threshold filters out short interactions.
4. After recording, select Open Profiles.
5. Sort by duration, SQL calls, HTTP calls, and correlation ID.
6. Open a profile in Performance Profiler and analyze it using the workflow in section 1.

Notes

• Activity types include browser activities, background tasks or job queues, and web service calls.
• Scheduled profiling introduces a small performance overhead through recording.
• A debugger, including Snapshot Debugging, cannot be attached while profiling is scheduled for the session.
• Profiles may appear with a delay because processing is asynchronous; refresh the page before concluding that no data was captured.

3) Database Locks page

What it is A client page showing a snapshot of all current database locks to quickly identify blocking situations.

Microsoft Learn: https://learn.microsoft.com/en-us/dynamics365/business-central/admin-view-database-locks

When to use it

• Users report hanging actions or intermittent timeouts.
• Posting or batch processing waits unexpectedly.
• You suspect lock contention between parallel processes.

Typical value Quick identification of active lock contention to narrow down the blocked process.

Related: https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/monitor-database-locks

4) Database Missing Indexes

What it is A recommendation page, Database Missing Indexes, that identifies possible indexes based on SQL workload observations.

Microsoft Learn: https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/database-missing-indexes

When to use it

• Queries are expensive and scan large amounts of data.
• The Performance Profiler call tree indicates SQL-heavy bottlenecks.
• Table access patterns changed after a feature was introduced.

Typical value Prioritized index candidates with an estimated benefit for optimizing particularly important tables.

Important note Treat recommendations as input, not as automatic instructions. Check for overlap with existing keys, write overhead, and storage requirements before implementing them.

5) Manage Database Index Usage

What it is A capability using Table Information and Table Data Management to review index usage and enable or disable indexes per company or for all companies.

Microsoft Learn: https://learn.microsoft.com/en-us/dynamics365/business-central/manage-indexes

When to use it

• You want to reduce write overhead and storage usage from rarely used non-unique indexes.
• You need to evaluate usage statistics for a table or company.
• You need company-specific index optimization.

Typical value Controlled index optimization based on observed usage.

Operational behavior

• Only eligible non-unique indexes can be disabled; primary keys, unique indexes, SIFT indexes, and $systemid indexes are protected.
• Disabling an index takes effect immediately.
• Enabling an index is queued for the next scheduled process at midnight in the cloud.

Important note Make decisions based on measured usage data. Disabling useful indexes can impair read performance.

6) Debugger with Call Stack + MCP Server for Troubleshooting

What it is The Troubleshooting MCP Server for AL is an AI-assisted debugging capability for active AL debug sessions. Copilot can inspect call stacks, variables, source code, and breakpoints.

Microsoft Learn: https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-debug-mcp-server

Prerequisites

• An active AL debug session in Visual Studio Code.
• Execution is paused at a breakpoint or because of a runtime error.
• The AL Language extension is installed and GitHub Copilot Chat is enabled.

When to use it

• You need an in-depth analysis of AL runtime errors and complex call stacks.
• You need to compare variable states across multiple calls.
• You want Copilot to suggest a solution based on the call stack, variables, and code context.

Typical value Faster root-cause identification by combining debug state with Copilot analysis.

Core MCP tools

• Get stack frames: Shows the call path to the current position.
• Get variables: Inspects local and global variables for each execution step.
• Get source code: Returns the source context for the current breakpoint.
• Add breakpoint: Programmatically sets a breakpoint.

Prompt example For example: “Use the Troubleshooting MCP Server to analyze how this error occurred. Then show the variables for frames 0 and 1 and suggest a solution.”

Limitations

• Available only during a paused debug session.
• No time-travel debugging.
• The scope is limited to the current call-stack context.
• Verify Copilot’s results against expected variable values before changing code.

When traditional debugging is better

• Interactive step-by-step execution through the code.
• Quick visual inspection of simple issues.
• An initial introduction to an unfamiliar code path.

7) Telemetry (Application Insights)

What it is Centralized runtime telemetry for long-term performance analysis across multiple sessions.

Microsoft Learn: https://learn.microsoft.com/dynamics365/business-central/dev-itpro/administration/telemetry-overview

When to use it

• Issues occur intermittently or only in production.
• You need trends across releases or comparisons across companies, users, and time periods.

Typical value Objective evidence of recurring patterns and regressions.

8) Database Wait Statistics page

What it is SQL diagnostics for analyzing wait times.

Microsoft Learn: https://learn.microsoft.com/en-us/dynamics365/business-central/database-wait-statistics

When to use it

• The bottleneck is caused by SQL.
• You suspect query-plan regressions or significant wait times.

Typical value A clear distinction between problems caused by locking, I/O, CPU, and query plans.

9) Page Inspection

What it is A diagnostic tool for UI and pages to investigate controls, table data, and extensions.

Microsoft Learn: https://learn.microsoft.com/dynamics365/business-central/across-inspect-page

When to use it

• Users report slow page opening or navigation.
• FactBoxes or FlowFields are suspected as the cause.

Typical value Targeted optimization opportunities at the UI level.

10) Job Queue logs

What it is Logs for scheduled or background processes and their overlaps.

Microsoft Learn: https://learn.microsoft.com/dynamics365/business-central/admin-job-queues-schedule-tasks

When to use it

• Slowdowns occur at predictable times.
• Posting and job queue tasks overlap.

Typical value Better scheduling and fewer contention peaks.

11) Snapshot Debugger

What it is A production-safe debugging approach for scenarios that cannot be reproduced in a test environment.

Microsoft Learn: https://learn.microsoft.com/dynamics365/business-central/dev-itpro/developer/devenv-snapshot-debugging

When to use it

• The issue occurs only in production.
• You need a call trace without attaching interactively.

Typical value Safe production diagnostics for difficult-to-reproduce issues.

Suggested Investigation Flow

1. Confirm and reproduce the issue (scope, user impact, and frequency).
2. Use Session Events / Active Sessions to determine the scope and affected requests.
3. Use the Scheduled Performance Profiler for a stable baseline and intermittent issues.
4. Capture the scenario with the Performance Profiler (in-client) and identify hotspots (Active Apps -> Object Time -> Call Tree).
5. If there are signs of waiting, check the Database Locks page.
6. For SQL-heavy issues, evaluate Database Missing Indexes, table and index characteristics, and SQL waits or query plans.
7. Use the Debugger + call stack, or the Snapshot Debugger in production, to verify the root cause in the code.
8. Use telemetry to validate improvements after release.
9. Run the baseline scenario again to confirm a measurable improvement.

Guidance by Audience

For customers / key users

• Start with the symptoms: Which page or process is affected, when does it happen, and how often?
• Provide timing examples and the affected users.
• Use lock and performance pages primarily to collect evidence.

For developers

• Work from measurement to diagnosis rather than from assumptions.
• Correlate the AL call stack with SQL and lock observations.
• Validate every optimization with before-and-after measurements.