Excel 2013 crash - related to digital signature?

Question

This is a cross-posting of a thread originally started in Microsoft Answers (Office- Excel) forum, advised to post in this forum by MS support engineer Mohan Suryanarayan (link to other forum: here).
I have a VB macro in file A (which otherwise contains only several Excel Tables with named ranges). My digital signature (for signing code) is attached to file A.
As the macro executes, the Open file dialog is called up so that the User can select a secondary file to open (file B or C).
Files B and C contain several sheets with formulas and Excel Tables, and also their own extensive VB macros. My digital signature is also attached to files B & C.
The remainder of the macro in file A simply executes an update of the Excel Tables in the secondary file, before saving & closing it.
I have been finding that during execution of the file A macro, Excel crashes and closes all open Excel files.
If I remove the digital signature from the secondary files then the macro in file A executes with no problem.
The macro was written in Excel 2007 and on a different laptop, with different digital signature, and used to have no problem at all. When a new laptop was purchased a new digital signature was obtained and placed into all of the files.
Execution of file A is a critical process - I need help with stopping the crash, while maintaining a digital signature in the secondary files (so that their own macros can execute).
Event Viewer error shows the following:
Faulting application name: EXCEL.EXE, version: 15.0.4667.1000, time stamp: 0x543d366c
Faulting module name: mso.dll, version: 0.0.0.0, time stamp: 0x5447696f
Exception code: 0xc0000602
Fault offset: 0x011aafdd
Faulting process id: 0x2d58
Faulting application start time: 0x01d01e17eafcd0bb
Faulting application path: C:\Program Files\Microsoft Office 15\root\office15\EXCEL.EXE
Faulting module path: C:\Program Files (x86)\Common Files\Microsoft Shared\Office15\mso.dll
JL Latham replied:
Tom, all I can give you is relatively non-information.  I haven't experienced that type of behavior even in Excel 2013 with digitally signed macros in multiple workbooks.  But my digital signature is a commercial one from DigiCert, not
self-cert.  I'm not even sure what piece of Excel or Office processes the digital signature (that is, whether it is mso.dll or not).  But your whole process has more moving parts than most of mine involving multiple workbooks do - I quite often turn
off .EnableEvents when doing things like that just so event driven macros in the other workbook(s) do not execute.
Do the macros in the 'B files' have to execute during all of this processing in file A?  If not, have you tried turning interrupts off:
Application.EnableEvents = False
before starting to work with the B-files?  Maybe something in them, such as a Worksheet_Change() or other event triggered process is messing things up?
If you do use  Application.EnableEvents=False, remember that you MUST re-enable that later in the code with Application.EnableEvents=True to get responses to things like button clicks, changes in a worksheet or other event driven processes
to run 'normally' again.
Have you looked at this discussion:
http://answers.microsoft.com/en-us/office/forum/office_2013_release-excel/excel-2013-crashing-immediately-when-attempting-to/ea2ab100-5525-4a0d-a3cf-6977319f954f
Sounds very similar to yours - original signature created in 2007, and crashing in 2013.  Some suggestions were made, but whether they fixed the issue or not is unknown: OP never came back and said "fixed it" or "didn't fix it".
I replied:
In answer, the secondary B files don't execute any part of their macros during the A file process, and I hadn't included an EnableEvents = False within the file A code. However, I have just tried it to check if it made any difference and unfortunately it didn't.
I had read the thread you gave a link to before posting, and also the sub threads given within that one, but didn't see anything I thought of immediate parallel other than an Excel 2013 crash.
The way I read the linked thread was that a User added a signature in Excel 2007 and when they tried to open the file Excel (2007?) crashes, although other people using Excel 2013 can open it (not clear whether it means others can open the one with
the 2007 signature or without it).
Anyway, the differences in my situation are that:
(1) my B-files were originally created in Excel 2007 on a different laptop to current and had their own signature attached. I maintain a 'stock' of B-file versions, some of which have the old signature and some the new. If I run the A-file macro
on one of the B-files with the old signature then it executes ok;
(2) I am able to open the B-files ok, no matter whether the signature in them derives from the old laptop with Excel 2007 or the new laptop with Excel 2013;
(3) the macros within the B-files execute ok (this includes any versions of the B-files which still have an old signature attached, by removing the old signature and replacing with the new and executing on the new laptop);
(4) the offending operation which triggers the crash (when the B-files have the new signature attached) is a Resize of the Excel Tables within the B-file. I understand that I may eventually have to find a workaround for this operation but initially
I want to sort out the signature issue (I'm reasonably sure the signature issue is not a red herring where the Resize is the 'real' problem).
Regards, Tom

Answer 1

Hi,
According to your description, this issue occurred with some particular files that stored in SharePoint site. Did the user  download the file to local disk to print?
Based on the event log >>Faulting module name: EXCEL.EXE<<, it does not show the root Faulting module. Thus, please try to follow this KB to do general troubleshooting:
https://support.microsoft.com/en-us/kb/2758592
Then, if you have used "printer status application", please go to Device settings -> Installable options -> Printer Status notification and select disable.
If this issue still exists, we may need to collect the App crash dump file:
https://technet.microsoft.com/en-us/sysinternals/dd996900.aspx
You can try to analyze dump by yourself if you would like to：
How to analyze app crash dump file:
http://blogs.technet.com/b/askperf/archive/2007/05/29/basic-debugging-of-an-application-crash.aspx
Regards,
George Zhao
TechNet Community Support
It's recommended to download and install
Configuration Analyzer Tool (OffCAT), which is developed by Microsoft Support teams. Once the tool is installed, you can run it at any time to scan for hundreds of known issues in Office
programs.
Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact [email protected]