Even though I have previously written and taught in a variety of classes and webinars the concepts of differential diagnosis, I decided to re-visit this topic as a result of questions and 'eyebrows' raised by students at my last Super Geek 201 course held during Scaling New Heights 2018.
Last time (Part 1) I introduced the concept of differential diagnosis and we went over the fundamental principles of the technique as used in 'medicine,' but also posed the question of the use of these concepts in determining irregularities with QuickBooks. One of the major teaching tools used in medical training related to giving a diagnosis are flow-charts, of course now days they are called 'clinical algorithms.' Near the end of Part-one I presented such a clinical algorithm associated with 'a bad cough' so you could get a better understanding of the 'rule-in/rule-out' process used in differentiation of a potential diagnosis.
We looked at what physicians refer to as the 'Chief Complaint' (as in the example of a 'bad cough') and how they then proceed through a series of assessments including a history of that Chief Complaint, and a patient medical history, along with measurable signs (like respiratory rate, breath (lung) sounds, chest percussion). Along with other tests like perhaps a check X-ray or even more sophisticated techniques to ultimately reach the point that they can either rule-out, or rule-in the various possibilities and probabilities of the cause of the patient's 'bad cough.'
The key in diagnosis is knowing what information to gather, and how to interpret the information obtained. Well, diagnosis of a QuickBooks issue is really no different. ProAdvisors are typically confronted with a 'chief complaint' from a QuickBooks user like, "QuickBooks just crashed."
As with the 'bad cough', the key to diagnosing the QuickBooks issue is in knowing what (and how) to gather the information you need, and understanding or interpreting the information properly. If our QuickBooks User's chief complaint is "QuickBooks just crashed" then we need to begin our assessment with a 'history of the chief complaint' in exactly the same way that a physician would conduct a history of the patient's chief complaint of a bad cough.
Differential Diagnosis Re-visited Part 2 Figure 1
Remember a history is really just a way of gathering and documenting the questions needed for assessment purposes. In our case a history of the "QuickBooks just crashed" chief complaint should include asking the user questions like:
- What were you doing ‘exactly’ when QuickBooks crashed?
- How long had you been doing that exact thing? (long time, just started, etc.)
- Were you in multi-user or single-user mode, were others working at the time?
- Did QuickBooks display any specific error message, if so what was it?
Of course, the obvious way to garner this information would be to ask the user, but many times QuickBooks users have conveniently forgotten the specifics of the incident. A friend of mine suggested the construction of 'flash cards' of QuickBooks 'shut-down errors' and then told me I should conduct a line-up with the user asking if they could identify the culprit (from the various flash cards, like criminal 'mug shots'). While that sounds like a good idea, and tends to fit in-line with my philosophy that a QuickBooks incident should be 'treated like a crime scene,' the similarity of such error messages might likely lead to a false identification.
Differential Diagnosis Re-visited Part 2 Figure 02
To that extent, it is always best to preserve the crime scene by making a 'Windows copy' of the entire directory containing the QuickBooks file that crashed. This copy will be used for analysis and testing rather than our doing our diagnostic and repair work on the live file until we are certain that we can safely proceed without doing more damage. (Note: In many cases I preserve even an additional copy saved to a flash drive so that I am certain to have sufficient back-up. But even though I used the term back-up this is not an actual 'back-up copy' it is a Windows copy of the data.)
Hopefully the user can remember a few answers, but it may take some other 'data detective' work on our part to track down the truth of these questions. One place to start looking for the truth is the QBWin.log resident on the computer where the 'crash' took place. If you were called to investigate the problem soon enough the QBWin.log file may still be preserved like evidence waiting for collection. The illustration below shows the location of the QBWin.log within the Windows file structure.
Differential Diagnosis Re-visited Part 2 Figure 03
Note that in addition to the current QBWin.log file there are several older versions of the log which have been preserved as QBWin.log.old1 (.old2, .old3, etc.). Each is progressively older than than previous, the higher the old# the older the file. If QuickBooks has 'crashed' on this computer you are not interested in the current file; if QuickBooks has been re-started, you are interested in looking at the older log files. If the user can tell you when the crash occurred you are likely to be able to identify which of the older log files should be reviewed. But when in doubt, make a Windows copy of all of the log files so as to preserve them because each time QuickBooks is re-started a new QBWin.log file is created, and the older files are incremented as the previous current file becomes the .old1 file.
When QuickBooks crashes the last line of the QBWin.log file for that session of QuickBooks should give you some ideas as to the error or cause of the crash, typically the log will record a 'fatal error'. In the excerpt from a QBWin.log file below, the fatal error has been highlighted in the red box.
Differential Diagnosis Re-visited Part 2 Figure 04
But in other instances, while the log may reflect a fatal error at the very end, the actual error resulting in the fatal error may have occurred prior in the sequence of events leading up to the fatal moment, as shown in the illustration below.
Differential Diagnosis Revisited Part 2 Figure 05
A good 'diagnostician' would examine all of the evidence not just the final life moment in the QuickBooks session. This is where expanding the history beyond the Chief Complaint comes into play.
In seeking the answer to the question about 'what had the user been doing' prior to the crash the QBWin.log can provide valuable information to either rule-in or rule-out what the user may tell you. Of course, if the user doesn't have 'a clue' as to what they were doing then we can still use the QBWin.log file to identify the work being accomplished. In the example below, the 'keen eye' of our Data Detective has identified the work being performed (in this case a report being generated). We can even see when the specific report was finished and how long it took.
Differential Diagnosis Revisited Part 2 Figure 06
The QBWin.log file is a wealth of information like this if you only know where and how to look, and how to interpret the information once you find it.
In our next installment of this mini-series (Part 3) we will look at how flow-charts can be used to help us differentiate the potential answers and solutions to our QuickBooks problems.