Appcrash opening Dynamics.exe

I worked on a critical call escalated from our support desk today.

Dynamics.exe was crashing on two of our clients Citrix Servers when the application was being opened.

What was strange is that both of the servers got the same problem at exactly the same time. Initially, working with our infrastructure team, we thought this might be to do with Windows Updates/.NET.

Upon further investigation, I found that it wasn’t.

I checked Event Viewer and found just a generic error message:

At this point, I decided to use a tool called Procmon, a Windows Sysinternals utility. This allowed me to see what files were being accessed by the dynamics.exe process. After I applied a filter for Dynamics.exe I ran the application and, after Dynamics crashed, was able to look at the log of files being accessed.

The last file on the list was R1058.DIC, Dynamics GP’s Interfund Management Reports dictionary.

Armed with this information, I was positive that a file in the installation was corrupt. Although the R1058.DIC was the last file on the list, it may not have been this file that was corrupt, but decided to try and replace the file anyway.

After backing up the installation directory, I copied the file from one of the servers that we knew was identical and was working. GP now opened and ran fine. I followed the same steps on the second server and fixed the issue with the same file.

Very strange that this happened on both servers at the same time, with the same file, but glad we were able to resolve the issue for our client quickly and efficiently.

So, if you are getting a random Appcrash problem, it might just be your dictionaries!

 

 

Share on Social Media:

Configuring Field Level Security

In one of my previous posts, I said I was going to make another post that shows how to set up Field Level Security. Below is a guide on how to set up Field Level Security to hide the Hold field from users on the Creditor Maintenance window. You can, however, use the same guide to set up any kind of Field Level Security by choosing the required security method when you get to the Field Security Maintenance window.

  • Log in as sa, DYNSA or whichever user you have set up to administer these changes.
  • Browse to the Administration Series > Setup > System > Field Level Security.
  • Enter your system password (if required).
  • You will be presented with the Field Level Security screen. Click Add.

  • The Field Level Security Maintenance screen will open; give your Field Level Security ID a reference and description.

  • Drill in to the spyglass next to Product Name.
  • The Resource Explorer will open.
  • On the left hand side of the screen, browse to your desired window. In this case, I am using Creditor Maintenance.
  • This is in Dynamics GP > Purchasing > Creditor Maintenance > Main: Creditor Maintenance

  • On the right hand side now you can select which field you want to apply the security method to. You can also tick the ‘Show Expanded Fields’ box to be able to choose from more.

  • In this instance I chose the Hold field, select which field you would like and click OK.
  • You can now select which mode you would like in the drop down menu, in my example I have chosen to hide the Hold field.

  • Once you’ve chosen your security method, and entered the Password ID if you’ve chosen to password protect the field, you can assign your new Security ID to users.
  • First, select the company you want to apply this to, select the user and tick the box of the Field Security ID you want to assign.
  • You’ll now notice at the bottom that it says a change is pending, this number will increase depending how many changes there actually are to apply.
  • Click Apply; your Field Level Security is now assigned to the user you specified.

As you can see, Hold is now hidden on the Creditor Maintenance window for user sa. Follow the above steps for all of your Field Level Security, as you can see, it’s easy to set up and a very useful extra level of security to control what your users can and can’t do within Dynamics GP.

 

 

 

Share on Social Media:

Error deleting company in Management Reporter

I was in the process of moving Dynamics GP and Management Reporter for a client and came across an issue deleting a company in the Configuration Console for MR.

It seems that my client had old companies listed which they could not get rid of. When trying to delete the company in the Configuration Console, the following error would come up:

This company is referenced by an existing report definition or reporting tree definition. Remove these associations before deleting the company.

My client had already checked through all of their Report Definitions and Tree Definitions and the old companies were not referenced.

I decided to have a look at the database and see if there were entries linking the company somehow.

My first port of call was to find the Company IDs of the companies in question. To do this, I ran the following in SQL Management Studio against the ManagementReporter database:

SELECT * FROM ControlCompany

I got the Company IDs from the ID column and then ran the following:

SELECT * FROM ControlReport WHERE COMPANYID = 'XXX'
SELECT * FROM ControlTreeDetail WHERE COMPANYID = 'XXX'

The COMPANYID is the ID that you picked up from the ControlCompany table. This showed a multitude of results, which confirmed my thoughts that there are linked in the database, even though none can be found in the Report Designer UI.

I now knew that it was necessary to remove data from the database.

WARNING:

ALWAYS BACK UP YOUR DATABASE BEFORE DELETING OR AMENDING RECORDS AS A PRECAUTIONARY MEASURE.

From here, I deleted the records relating to the old companies in SQL:

DELETE FROM ControlReport WHERE COMPANYID = 'XXX'

DELETE FROM ControlTreeDetail WHERE COMPANYID = 'XXX'

Once these records were gone, I was able to delete the old companies through the Configuration Console.

 

 

Share on Social Media: