Understanding Software Issues: Hangry software

[TinaMorgan1]

We have all been there.  Your stomach is growling, yet all of your mental energy is focused on fixing the car in front of you going fifty in the fast lane.  When people are hangry (hungry/angry) they may come off irritable and agitated, maybe even point out every little thing that is going wrong, when the issue at hand is as simple as “I am hungry.  Feed me!”. 

Misdiagnosis happens all the time and can translate into many other facets of life, including software issues, but could you diagnose software issues when it seems like your software is being hangry?

The good news is that with some practice, and skills of observation, anyone can categorize software issues like a pro.  This blog will help guide you when encountering software issues.  The intention is to lift the many layers that can complicate issues, so that you may accurately, yet simply state the issue you need help with.

Symptoms of software issues are observable by the end user in many forms, such as an error, performance degradation, or a software crash, to name a few.  Hopefully, these interruptions prompt users to call to Esri Support and log a case for investigation.  At Esri Support, our analysts have a specific skillset.  Few of us are generalists, and this structure is designed to provide our customers with elite technical support…in other words, we don’t use scripts. 

Why is this important?  One of the first steps to logging a case with Esri Support is providing a description of the issue, which will be used to form a subject line in the case.  These subject lines can be altered as more knowledge is gained on the issue through investigation, but this initial subject line is big factor in determining which analyst owns the case first. 

Determining the overall symptom helps guide the triage process and the lifetime of the case.   Let’s explore these symptoms in more detail.

1.  Error: 

Error messages will stop us in our tracks.  Sometimes the messages are very useful, and tell us exactly what we need to know to proceed, sometimes not so much.  When users encounter errors we always request a screenshot of the error and the workflow (clicks) leading up to the error.  For example, “Error: invalid coordinate system identifier” is seen when adding data from an Oracle enterprise geodatabase into ArcMap.

2.  Performance degradation:  

Personally, this is the most frustrating issue to encounter.  There is no error; instead, the process is slow, and the spinning hour glass doesn’t tell you when you can expect performance to return.  When performance cases come to my desk, I first gauge the slowness, because “slowness” is a relative term, and something that is slow in one environment may be optimal in another.  The symptom here isn’t just performance, but specifically performance degradation.  In other words, there was a more optimal performance, which has now degraded.

Symptoms of slow performance can be caused by many things including workflows, overloaded resources, and software compatibility to name a few.   To get started troubleshooting it is always helpful to have a comparison case available for investigation.  If you believe you are seeing slowness in software, first ask yourself ‘this is slow compared to what?”  

For example, “using ArcMap 10.1 sp1 to do the same workflow on the same data takes 1 seconds, while using ArcMap 10.5.1 takes 20 seconds”, or “Previewing feature class A in ArcCatalog takes 1 second, while previewing feature class B takes 20 seconds.  Both features are stored in the same enterprise geodatabase”. 

These examples give us a “fast” example and a “slow” example that can be compared to each other.  Notice in these examples that there is only one difference in the workflows, giving us controlled variables and a single dependent variable to review…right, like scientists.

3.  Unexpected results:  

This symptom, like performance, will not produce an error, but unlike performance symptoms, these processes will complete, seemingly successful.  However, when the results are analyzed they are incorrect or incomplete.   Unexpected results can also take the form of tools being disabled, or grayed out. 

For example, “I open ArcCatalog to enable Editor Tracking on my feature class, but Enable Editor Tracking is grayed out”, or “I created a replica of my U.S. States feature class, but only 48 of the states were replicated into the child geodatabase”.

Most of the time unexpected results stem from a workflow issue.  Some setting that needed to be turned on for this tool to work was not turned on, or properties/constraints on this data caused the unexpected results.  In the first example above the connection must be made as the data owner to enable Editor Tracking.  Any other user connection will see the Editor Tracker option grayed out.  The second example, where not all data has been replicated, may be due to filters placed on the data being replicated, or relationship classes enforcing database referential integrity.  

4.  Crash:

Click, click boom goes the dynamite.  There is no error.  The best you can do is re-open the software and try again.  Esri considers all crashes a bug.  We want our software to give you a meaningful error that will help you complete your work.  Crashes occur when the software encounters an argument that it doesn’t know how to resolve.  Always report crashes to Esri Support so we can ensure our software understands how to handle these situations.

Software issues can be complex, can employ multiple technologies that require different levels of expertise on many different subjects.  These issues can be more approachable by answering the question, “What did I observe during my daily work that prompted me to request help”?   While there are always exceptions, 90% of the time I can start answering that question with one, or more, of the symptoms discussed in this blog.   I hope this helps brighten up the perceived darkness around software issues, and as always, give us a call if you encounter any of these issues, or just have questions for us. 

esrisupport‌

[DanPatterson_Retired]

Another bookmark keeper!

[JoshuaBixby]

Good information, thanks for writing up and sharing.

[GeorgeHouck]

Speaking of reporting errors... I have been reporting the CRASH that happens when I pan or zoom in Layout mode for 3 months now and I have NEVER received feedback, nor have I heard of a fix.

      -George

[TimWitt2]

Nothing worse than 999999!

[TinaMorgan1]

Please report crashes to Esri Support.  We treat those as bugs as we would like the software to tell you something meaningful when it encounters issues, rather than just shutting down because it doesn't know how to handle some call.

We will want the following:

1.  Files:  crash error report, any applicable log files, RDBMS traces and sdeintercept if applicable.

2.  Exact workflow: start from "1.  Open ArcMap <version>, 2.  Add data from location <my complete location to the data>"

3.  Configuration information:  ArcDesktop version (including any patches and/or service packs),  operating system details.

4.  Data information:  Is there data in the map?  Where is it coming from? 

5.  Patterns:  Does this happen for all users (run ArcMap as a different user to test)?, Does this happen for all desktop machines?  Does this happen for all data (create blank maps and add different datasets to test, use simple versus complex data if you think this could be part of the issue)

WHY ALL THE QUESTIONS?  

1 and 2 are pertinent to understand the issue and test in house.  Traces and logs can tell us exactly what is happening in the back end.  

3 is the first layer of troubleshooting "does this crash occur in an Esri supported and certified environment?"

4, as a database person, this one helps me understand more about the structure of the data and how the client deals with it.  

5 helps us understand if the crash is occurring due to some corruption to a user's profile, possible other software/hardware on a particular machine that the client takes issue with, or if specific data types may be causing the crash. 

[TinaMorgan1]

I like a challenge!  999999 basically says to me that a call was made to or from the client, but the client does not know how to handle this call.  If you are using an RDBMS as your database/geodatabase then 9 times out of 10 I find the answer in the RDBMS trace file.  

999999: Error executing function.—Help | ArcGIS Desktop 

Tips on taking a trace to troubleshoot client issues:

1.  Document EACH CLICK from opening the Arc product until the error.  Know what clicks are necessary and what clicks are not necessary.  For example, if part of the workflow is to add data to ArcMap, and if the symbols are not part of the issue, do not take the time to symbolize this data.   Write your clicks down!

2.  Close all Esri application on the desktop where you receive the error.

3.  Set up your trace to capture detailed info (choose proper events in SQL Server, use level 12 in Oracle, etc)...do not start the trace yet.  This may take coordination with a dba.

4.  Set up the sdeintercept on the desktop where you receive the error.

5.  Start your dbms trace (I like session based traces, or logon triggers in Oracle).  The intercept will trigger to be created as soon as you make a connection to your enterprise database from the Arc application.

6.  Follow your documented workflow exactly.  See the error.  Document the time down to the second.  Stop your trace and close all Arc applications.  Harvest your trace and intercept files.

This gives us a database trace that tells us all the calls the database sends and receives, and a client intercept that tells us all the calls the client sends and receives.  With the timestamp and the clicks of the workflow we can seriously get some information here!

[TimWitt2]

TMorgan-esristaff I'll let you know next time I run into a 999999 issue and I can't find an answer in the forums (which surprisingly answers my question with a high percentage).

[GeorgeHouck]

Shouldn't the POPUP ask us these questions? When it happens your boss is inevitably over your shoulder asking for obscure piece of info and you need to reboot immediately to get an answer to a County Commissioner.

The popup is not user friendly, nor does it seem to ask for half of what you say in "required" for e response.

[TinaMorgan1]

George, 

I am so sorry I overlooked this post back in November!

My understanding of the crash pop up is that it does go to an Esri development team for review, but unfortunately I do not have much more insight on it than that.  I will see what I can find out.  

This article, though, is more specifically when the user who sees a crash wishes to contact Esri Support for investigation of those issues.  It is common that users ask us "Why all of the questions", so this was in hopes going to clarify why.  

If you listened to Car Talk, it's the same scenario.  Someone calls in with a description of an issue.  Ray and (the late) Tom would then have to ask clarifying questions like "do you hear the rattle when the air conditioning is on?  Now is it a rattle or a screeching sound or both?  What year is your car?", because they understand the mechanics used to run an air conditioner.  Your answers help them give effective advice like "since this is an older car, and it only happens when the AC is on, and it is a rattle with a screeching sound I'd say check your Serpentine belt.". 

As mentioned, a crash is a bug in our eyes.  We do not want that to happen.  I encourage you to call support to report the crash if it is still happening.