
QuickBooks is still throwing encryption failures even under QBES-2013R8. QuickBooks Enterprise has had a long history of encryption errors, and this has seemed to increase under QBES-13; however, part of the updates in recent versions were supposedly aimed at resolution of these issues. For example Intuit’s release notes for QBES-13 R7 indicates that R7 resolves “multiple encryption/decryption errors” and that “QuickBooks will no longer display the error LVL_SEVERE_ERROR—GetMasterKey Failed: The decryption has failed.” At the same time, the release notes also specify that the QBWIN.LOG file will provide ‘improved logging’ of encryption and decryption errors. It seems to be a significant contradiction to say that the encryption/decryption errors are resolved, yet at the same time advising that the QBWin.log file will report such errors with better information for resolution. (Does the right hand not know what the left hand is doing?)
Subsequent to R7, Intuit must have realized that cause of encryption/decryption errors, supposedly resolved had not been corrected because they issued a replacement for earlier Knowledge Based Articles on the subject. KB ID# SLN71415 titled “Error: QuickBooks found a problem with the Acct # / Card #/ Note field for other asset” (as seen in our title illustration) begins by saying, “In QuickBooks, 2013 R7 and later…”, the KBA goes on to specify that you may see the following message in the QBWin.log:
DMEDLEditListElement.cpp (127): CHECKPOINT: 6204: Tue Mar 19 14:24:07 Decryption error in [Record Field Name] for '[Error Displayed Name]': Failed. The decryption has failed. (Editor’s note: The key words in this error are “Decryption error” and “The decryption has failed.”)
R7 did not resolve these encryption/decryption errors, nor has the R8 release resolved them even though the hype has been that R8 resolved everything that R7 didn’t fix that it was supposed to fix, as well as the additional bugs that R7 produced. While some reports indicated that with R7 the Rebuild Data utility would resolve these errors, the Intuit KBA (SLN71415) warns against using the Rebuild utility saying: “IMPORTANT: If you receive this message with QuickBooks opened or the error displays in the Qbwin.log, do not rebuild because this will not fix the issue and can cause additional problems…”
My own blog reported on the R7 release’s encryption/decryption error related capabilities this way: “R7 was also intended to deal with several ‘encryption/decryption’ errors that have plagued QuickBooks in recent versions, especially as they relate to credit-card numbers. Some users report that the R7 update actually made these problems worse; in some cases credit card data, social security numbers, and other critical information was actually corrupted to the point that some functions would not even work. Users reported having to manually rebuild this data into the file by first removing any traces of these fields, then saving temporary information, then re-editing the fields with the correct data. Clearly data damage of this nature could almost be a ‘lethal bite of the bug’ for some larger clients if 10’s-of-thousands of records were involved.”
Intuit’s KBA (SLN71415) seems to reinforce the assessment we published in our blog; however, I must admit that I had not seen any of these errors since R8 went live, nor had I read any exhaustive tracks regarding this issue since R8 in any of the forums or communities. As such I believed that R8 had resolved these issues; but after today I am convinced that the fundamental issues associated with these errors still exist within QuickBooks, and more specifically QuickBooks Enterprise 2013 even with R8 installed.
One day after taking a ‘clean file’ from QBES-2012 to QBES-2013 without issue, suddenly the client experienced the error reported in this articles feature figure; fortunately the client called me immediately without doing anything else and having all personnel stop working in the file. We were able to ‘limit’ damage and correct the problem by ‘creating a new QB user’ for the user whose password encryption was corrupted, removing and then replacing the ‘bank account number’ of the account exposed at the time of the error, removing and then replacing the ‘social security number’ of the employee whose paycheck was exposed at the time of the error, and forcing a replacement of the Admin password for the company file. Subsequent analysis indicated no additional encryption errors, and the Verify Data Utility confirmed none existed.
In conclusion, it appears that the past encryption/decryption errors associated with QuickBooks, especially QuickBooks 2013 still exist, they have not been resolved by either R7 or R8 and Intuit must be aware of these problems since they issued KBA (SLN71415) subsequent to R7. It is essential if you experience any of these errors that you do not ignore them and that you take immediate steps toward resolution. These steps may need to go beyond those published in the above referenced KBA and you may need to seek the assistance of a qualified QuickBooks ProAdvisor and/or QuickBooks Data Specialist to assist you in proper repairs before seriously compromising your company file.