How to Fix a Write to Setup File Aborted Error from the Support Debugging Tool

  • Article

David Meego - Click for blog homepageThis minor issue with the Support Debugging Tool has raised its head a few times, so I thought I would explain what is happening and how to resolve it.

The error message below is displayed by the Support Debugging Tool just after logging into Microsoft Dynamics GP: 

Write to Setup File Aborted. Saved File version (##.##.####) is newer than the Support Debugging Tool version (##.##.####) on this workstation.

This dialog is displayed when the version and build number stored in the Support Debugging Tool's Debugger.xml setup file is from a newer version or build than the version and build of the Support Debugging Tool dictionary installed on the workstation. This message was designed to ensure than once a system has been updated to a new build of the Support Debugging Tool that all workstations have the Support Debugging Tool code updated to match the system.

Once the Debugger.xml setup file has been updated for a newer build of the Support Debugging Tool, older builds of the tool will not save over the top of the file with an older format. This will prevent an older build of the tool damaging a setup file saved by a newer build and so avoids possible data loss for the settings.

Under normal circumstances, you will only ever see this message if you upgrade some but not all workstations on your system with a newer build. In this situation, the message will go away once you have updated all workstations to the newer build.

So, under what situations does this become an issue?

There have been two situations brought to my attention. They both have the same end result:

  • Installing a newer build or version of the Support Debugging Tool into a test system.
    At this site, there was a separate test server with a separate test application folder and the data on the test server was a copy of the live system. The Support Debugging Tool was set up in the recommended configuration with a shared location for the Debugger.xml setup file. Once launched, the setup file was updated to the newer build, then all workstations in the live system started showing the error dialog.
     
  • Installing a newer build of the Support Debugging Tool on one workstation.
    At this site, the newer build was installed on one workstation, so the System Administrator could look at the new features. Again the Support Debugging Tool was set up in the recommended configuration with a shared location of the Debugger.xml setup file. Once launched, the setup file was updated to the newer build, then all the other workstations in the system started showing the error dialog.

In both cases a newer build of the Support Debugging Tool updated the shared Debugger.xml set file as it was designed to do, but the rest of the system was not updated to match with the same build.

 

How to Avoid the issue

To avoid you need to break the link to the shared Debugger.xml before Microsoft Dynamics GP is launched.  These changes need to be made to stop the problem coming back each time the newer build is used.

To stop the Administrator Controlled settings being applied to the workstation, add the following setting into the Dex.ini file:

MBS_Debug_ConfigurationOverride=TRUE

To change the location for the Debugger.xml settings file to use the local Data Folder, remove the following setting from the Dex.ini file. Or you can edit the settings to change the location to a "different" shared folder:

MBS_Debug_Path=XXXXXX

Note: You can copy the Debugger.xml file from the old location to the new location if you want to keep the settings you have.

If using a test system and you want to point all test workstations to the new location, you can use the Dex.ini Configuration window to remove and reset the Administrator Controlled settings and then uncheck the "Do not update any Dex.ini settings automatically" checkbox.

 

How to Fix the issue

To fix an updated Debugger.xml settings file, please perform the following steps:

  1. Ensure all users are logged out of the system, so we can make sure we have exclusive access to the files.
     
  2. Go to the location of the shared Debugger.xml file with Windows Explorer. Look at the MBS_Debug_Path Dex.ini setting on a workstation, if needed.
     
  3. If there is a Debugger subfolder with a number of ctree cache tables (*.dat & *.idx), delete the contents of the folder. This cache was added at build 16 and will be recreated when Microsoft Dynamics GP is next launched.
     
  4. Make a backup copy of the Debugger.xml settings file to another location, just in case.
     
  5. Using Notepad.exe and check Word Wrap is off under the Format menu. 
     
  6. Then open the Debugger.xml file by dragging and dropping it into the Notepad window.
     
  7. Press Ctrl-F and search for "versionMajor", make sure the value in between the > and < is the same Major Version number as the current build installed. eg. 11.
     
  8. Press Ctrl-F and search for "versionMinor", make sure the value in between the > and < is the same Minor Version number as the current build installed. eg. 0.
     
  9. Press Ctrl-F and search for "versionBuild", make sure the value in between the > and < is the same SDT Build number as the current build installed. eg. 15.
     
  10. Press Ctrl-S to save and close Notepad.

Now the version information in the setup file will match the installed code and the issue is resolved. 

  

So just a final reminder to, "disconnect" any test systems from the shared location when using the recommended configuration before running a newer version of build of the Support Debugging Tool.

David