Debug::assert() method calls in SYS layer triggering Dynamics AX 2012 debugger

I’ve noticed a behavior in the RTM version (6.0.947.0) of Microsoft Dynamics AX 2012 that has been causing some problems for me lately. Specifically, there are some Debug::assert() method calls in the SYS layer that are being triggered in the application when running in a development environment with debugging enabled (client-side and/or server-side).

This issue does not appear to be entirely new because I’ve found blog postings related to this issue for Dynamics AX 2009:


I’ve actually run into this issue while attempting to post purchase orders using the AX 2012 client in a development environment with debugging enabled. Everything works fine until I try to invoice update the purchase order. Then the following dialog appears, and the AX debugger is invoked automatically.

On the client side, here is where debugging is enabled/disabled:

Microsoft Dynamics AX 2012 (client) > Tools > Options > Development > Debug

On the server side, here is where debugging is enabled/disabled:

Start (Windows) > Administrative Tools > Microsoft Dynamics AX 2012 Server Configuration

This issue generally won’t occur in a production environment because debugging will be disabled there. However, if you’re a developer, turning off debugging is not an option in a development environment!


I’ve dealt with this issue in my development environment by using the following technique:

  1. Identify the specific Debug::assert() method calls which are causing the application to halt.
  2. Comment out the offending Debug::assert() method calls.
  3. Add a //TODO comment as a reminder of the Debug::assert() method calls which were disabled.
  4. Add a “Temp” group to your project to hold any objects with disabled Debug::assert() method calls.
  5. When deploying to production, re-enable the disabled Debug::assert() method calls.


Technically speaking, Step #5 above is not really necessary because the Debug::assert() method calls generally will not be triggered in a production environment. The intention of Step #5 is “house-keeping” to restore code originating from the SYS layer to its original behavior.


I am rather surprised that this issue occurs in the first place – especially with Sys layer objects. The Debug::assert statement is not intended as a run-time validation mechanism for catching invalid user-provided input. Instead, it’s a tool that developers use during coding and unit testing to expose pre-condition failures in their method calls. I’m puzzled as to why any of these pre-conditions would fail for code residing in the SYS layer of the AX 2012 RTM version.

In my particular situation, I was simply trying to post a purchase order using the AX client in my development environment when I encountered this issue. I assume that the assertion failed for some reason other than any modification(s) that I might have introduced into my development environment. However, I haven’t thoroughly tested that assumption by attempting to replicate the issue on a completely new installation of AX 2012 RTM. Accordingly, that assumption is unconfirmed.

1 thought on “Debug::assert() method calls in SYS layer triggering Dynamics AX 2012 debugger

  1. if you check XReference – Used By for this method you’ll find it is called in many places in the same class.

    IMHO it is simpler for developer to use on Debug::assert( “is record NULL” ) than to provide dozens of If-Case scenarious in the calling methods, esp. if it is supposed by Application logic that the returned record must not be NULL.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.