Quick Tip: Why does Microsoft Dynamics GP show as Not Responding

I am wondering if Joseph Tews is a mind reader, or if he can somehow see my draft blog posts before they are published.  Joking aside, it turns out that the same day he posted about Symantec Endpoint Protection, he also posted about this topic that I was planning to post about. Unless he has a super power, then I will have to believe that these issues are faced by enough people to warrant multiple blog posts.

The issue for this post is one that almost everyone has seen at some time. Microsoft Dynamics GP or Microsoft Dynamics GP Utilities showing as Not Responding and maybe even receiving a dialog from the operating system offering to close the application forcibly. This is especially common when using Dynamics Utilities to create or upgrade databases.

 

So, I wanted to discuss what causes the "Not Responding" state and what actions should be taken when it occurs.

NOTE: If you terminate the application while it is still busy working and manipulating SQL data, you could cause data corruption and be required to restore a backup of the data.

Cause

In simple terms, whenever you swap focus to another application or move a window around to cover or expose another application, the Windows operating system sends a request to all the applications involved to redraw their screens.  If this does not happen within a short period of time, then Windows marks the application as Not Responding and will pop up a dialog offering to close the program.

The question here is .... Even if Microsoft Dynamics GP is not responding, has it stopped working? Usually, the answer is No.

The Dexterity runtime engine (on which Microsoft Dynamics GP runs) only updates the screens when control is returned to the user interface or when updating the user interface, so if the application is busy processing Dexterity code or busy waiting for SQL Server processing to complete and there is no changes to display on the screen, it will not redraw the screen and appear to Windows to be Not Responding. The truth is that the application is just too busy to update its screen and Windows (especially the newer versions) is just being impatient.

To get a little more technical, here is an explanation from my fellow Escalation Engineer, Aaron Donat:

The Dexterity runtime will usually have two or more connections to the SQL Server per client instance; which to Microsoft Dynamics GP is considered a foreground and background connection. When either a foreground or background process is executed by the Dynamics GP Client, those connections are invoked through the Dexterity runtime. When this occurs, the Dexterity runtime engine can end up in a “waiting state” for as long as the external process takes to complete and return. During this waiting period, the OS level “pings” from the Dexterity runtime will eventually stop functioning at given specific threshold. Once the OS level pings cease, the operating system takes and marks the application as “Not Responding” because of the lack of response between the two applications. This threshold is more clearly defined and pronounced on Windows 7 / Server 2008 operating systems than on Windows XP / Server 2003. In addition, the cause for this issue doesn’t specifically have to be a SQL connection that isn’t responding. Other cases could be large calculations, lack of hardware resource, a business logic issue within the application, an external application such as a Web Browser or Office Application using shared resources and anti-viruses.

As soon as it has completed what it is working on or has an update for the screen, it will redraw its window. 

Actions

So, how can I tell that Microsoft Dynamics GP is still running and that  I should just "Wait for the program to respond". 

There are five possible situations:

1. The application is running Dexterity code that does not access SQL data and just needs time to finish.
    
2. The application is running Dexterity code that does access SQL data and just needs time to finish.
    
3. The application is running Dexterity code that does not access SQL data and has entered an infinite loop.
    
4. The application is running Dexterity code that does access SQL data and has entered an infinite loop.
    
5. The application has frozen and is no longer processing.

For situations 1 and 3, it will be difficult to tell whether time will fix the problem.  You can watch the CPU usage in the Task Manager and see if it fluctuates (still working) or is maxed out (probably looping).  Fortunately, most activities in the application do involve some access of SQL data, and these situations are rare.

For situations 2 and 4, you can check if SQL Server is processing, you can use the Activity Monitor to see an overview of the activity that SQL Server is doing or you can start a SQL Profile Trace to watch the actually commands being executed.

For the Activity Monitor approach have a look at the MSDN article that Joseph Tews over at Summit Group Software referenced in his post: Server Installation Progress (Not Responding).

• MSDN: How to: Open Activity Monitor (SQL Server Management Studio)

For the SQL Profile Trace approach, start the SQL Server Profiler from the Tools menu. Connect to SQL Server and use the Events Selection tab to make sure the following events are selected. You might need to check the Show all events checkbox:

1. TSQL: SQL:StmtCompleted
2. TSQL: SQL:StmtStarting

For more information on how to use the SQL Server Profiler, see the MSDN articles below:

• MSDN: How to: Create a Trace (SQL Server Profiler)
   
• MSDN: How to: Specify Events for a Trace File (SQL Server Profiler)

Situation 4 can be identified with the SQL Profile trace, when the logged events keep repeating without changing the records they are working on. 

For situation 5, you will see no activity at the SQL Server level and probably no CPU usage in the Task Manager. In this case, you only course of action would be to forcibly close the application using Task Manager.

If you do have to forcibly close the application at anytime, you would be safest to restore a backup, or at least closely check the data that was being touched to ensure there is no data corruption.

Also check out this post form the Dynamics GP Support and Services Blog:

• Microsoft Dynamics GP Upgrade: Is it still running?

Hope this information is helpful. 

David

13-Sep-2012: Added Link to post by Chris Bulson.

Comments

• Anonymous
  August 12, 2011
  Excellent post! Especially during upgrades I tend to use a combination of SQL Profiler and DEXSQL.LOG to determine whether Utilities is processing or not. Also, I tend to monitor CPU and Memory usage for the Dynamics.exe process. While this may sound like an overkill, you will get "(Not Responding)" events when Utilities tend to manipulate large tables as they involve extensive record processing. MG.- Mariano Gomez, MVP

• Anonymous
  August 13, 2011
  An even more technical reason for why this is occuring is because the application is not doing multi-threading properly.  Most likely they are doing complicated work (SQL interactions) on the same thread the User interface is running in.  If they ran those operations in a different thread this problem would go away!  Please put that in as a product request (multi-threading through the application).

• Anonymous
  August 14, 2011
  Please log a product suggestion via Microsoft Connect. See the post below for details: blogs.msdn.com/.../providing-product-feedback-using-microsoft-connect.aspx

• Anonymous
  August 15, 2011
  I agree with Mariano, a very informative post. Well done David, and thank you.

• Anonymous
  August 17, 2011
  Posting from Jivtesh Singh at About Dynamics, Development and Life www.jivtesh.com/.../everything-dynamics-gp-19.html

• Anonymous
  August 17, 2011
  Posting from Mark Polino at DynamicAccounting.net msdynamicsgp.blogspot.com/.../quick-tip-why-does-microsoft-dynamics.html