Most Valuable Professional

View Jan Karel Pieterse's profile on LinkedIn subscribe to rss feed

Subscribe in a reader

Audit !!!

Check out our RefTreeAnalyser
the ultimate Excel formula auditing tool.


Visit our Amsterdam Excel Summit

Speed up your file

The best tool to optimise your Excel model!
Home > English site > Articles > Workbook Open Bug

Macro in Excel Stops After A Workbook.Open Command


Sometimes Excel VBA behaves unexpectedly. Here is an example:

You are running code that is meant to open one or more files using the Workbooks.Open command. As soon as you hold down the shift key when this command is being processed, macro execution stops and your program is terminated entirely. This will even happen if you are e.g. editing an email message in Outlook whilst Excel VBA is processing the code in the background.


Excel is designed not to run Auto_Open and Workbook_Open code when a workbook is opened from the User interface whilst holding down the shift key. Unfortunately, this (desired) behaviour also applies when opening workbooks through VBA code.

Microsoft has confirmed this is a bug.


Before opening a workbook through code, detect if the shift key is pressed and wait until it is released. The code sample below shows you how to do this:

 Option Explicit

'Declare API
Declare Function GetKeyState Lib "User32" _
(ByVal vKey As Integer) As Integer
Const SHIFT_KEY = 16

Function ShiftPressed() As Boolean
'Returns True if shift key is pressed
    ShiftPressed = GetKeyState(SHIFT_KEY) < 0
End Function

Sub Demo()
    Do While ShiftPressed()
    Workbooks.Open Filename:="C:\My Documents\ShiftKeyDemo.xls"
End Sub

This problem has also been listed in the Microsoft knowledge base:

Macro in Excel Stops After A Workbook.Open Command, February 26, 2005


Showing last 8 comments of 47 in total (Show All Comments):


Comment by: Martin (6/27/2014 11:47:45 AM)

Hello Jan-Karel,

I hope you can help me because I'm at my wits' end.

This is all in an XP/XL2003 environment

A macro of mine dies as soon as it has opened an external .xls file using What I mean is that after the debugger has executed the statement, the opened file stays open in Excel, but the debugger is no longer active and the call stack is empty. The problem is definitely not related to the shift button being pressed. It makes no difference if I open the file as read-only, add various 'on error' statements, or remove the workbook_open event from the target file.

What I do notice is that the opened excel file contains a bunch of "#NAME" errors, which only disappear when calculate full is executed using Ctrl-Alt-F9. If I open the external file directly (not using, the #NAME errors appear at first, and then go away automatically when Excel recalculates. The same thing happens if I save the external file after recalculation and re-open it.

I suspect that is bugging out on opening the file and finding the #name errors (or whatever caused them).

I'm not sure what is causing the #Name problem, although the external file has a lot of UDFs and Macros, including UDFs that evaluate names that refer to cells with UDFs in their formulas. Every so often I need to calculate.full to avoid #Errors when editing the external file.

Because the excel macro dies, I can't automate any processing of the target file in Excel 2003. If I run the macro in Excel 2010, it does not die after opening the same external file using, and everything works normally. Unfortunately the users of both sheets have XL 2003 and I can't change this.

Do you have any ideas for a workaround or a solution? Are you aware of any differences between in XL2003 and XL2010?

Many thanks in advance for having a look at this for me, I really appreciate it.

yours sincerely


Comment by: Jan Karel Pieterse (6/27/2014 2:45:26 PM)

Hi Martin,

I strongly suspect one (or more) of the UDF's run into a runtime error (which do not show up when the UDF is called from a worksheet cell or a conditional formatting formula!!).

UDFs require very strict design to make sure no runtime errors occur EVER when they are called. A RT error in a UDF can also cause the calculation chain to break and hence stop Excel from completing the calculation.

A simple way to test is to include an on error resume next at the top of each UDF.

Also, make sure none of the UDFs tries do do things UDFs are not allowed to do.

E.g. you are not allowed to change any formatting of cells and such, nor are you allowed to use the HasFormula property of a passed range object.


Comment by: Martin (6/27/2014 3:43:59 PM)

Hello Jan-Karel,

for checking the UDFs, the issue is that the UDFs in turn call a great variety of VBA functions. Wouldn't I have to put an error check in each one of these too? Also, how would an 'on error resume next' help detect a RT-error?

Why would the problem not occur under XL2010 if it's caused by a UDF RT-error? Is it simply because having a UDF RT-error causes arbitrary behaviour?

I will try to chase down if that is, in fact, the cause of the problem and let you know. If anything else crosses your mind in the meantime, do please let me know


Comment by: Jan Karel Pieterse (6/27/2014 4:05:15 PM)

Hi Martin,

The on error resume next was meant as a quick check to see if it alleviates the problem. Of course after that you would have to start finding out the root cause.

Indeed: RT errors triggered from a UDF can cause unexpected behavior. Excel 2010's calc engine is different from 2003's so I'm not surprised it behaves different in cases like these.


Comment by: Amar (10/21/2014 2:57:30 PM)

I was working on a macro and it was working perfectly fine.Later I had to get my laptop formatted and then when I run the macro it throws me an error saying...Run time error 1004. Microsft Office Excel cannot access the file 'C:\3EA66200'.There are several possible reasons.1) The file name or path doesnt exists.2) The file is being used by another program.3) The workbook you are trying to save has the same name as the currently opened workbook.



Comment by: Jan Karel Pieterse (10/21/2014 3:32:45 PM)

Hi Amar,

Looks like Excel tries to save in the root fo drive C, which normally is a protected folder (you would need administrator rights to write files in that location). Perhaps you need to change directory first?


Comment by: Natasha (11/19/2014 9:09:07 PM)

I stumbled upon this page because I wondered if I could put in a pause of some sort after using Workbooks.Open.
I have an excel (.xlsm) that gets opened by a program at certain times by a service running on a server. This is to email reports. One "summary" report excel opens 3 other xlsm's to get data. 2 of these xlsm's are a little heavy and do some calculations and take some time before they get populated with current info.

Here's an example of the VBA for opening one of them:

    LogInformation ("Opening Something")
    Set Something = Workbooks.Open("\\SERVER\folder1\folder2\BigExcelWithLotsOfCalculations.xlsm")
    Something.Application.DisplayAlerts = False
    LogInformation ("Something Open")
    If Not Something.Application.CalculationState = xlDone Then
    End If

Any way to slow or pause the process?

Thanks for your help,


Comment by: Jan Karel Pieterse (11/20/2014 10:37:07 AM)

Hi Natasha,

Normally, VBA code is stalled during calculations, you should not have to do anything to ensure calcs are done.
However, refreshes of external connections which are set to refresh on open are done asynchonously and hence can cause a problem.

What can be done to circumvent this is to turn off refresh on open for all connections and handle the refreshes using VBA, making them all synchronous by using the BackGroundQuery property of the Refresj method and setting it to false explicitly:

Sub Refreshall()
    Dim oPt As PivotTable
    Dim oQt As QueryTable
    Dim oSh As Worksheet
    Dim oLo As ListObject
    For Each oSh In Worksheets
        'Querytabellen die in oudere Excel versies gemaakt zijn
        'staan NIET in een tabel, evenals web queries
        For Each oQt In oSh.QueryTables
            oQt.Refresh False
        For Each oLo In oSh.ListObjects
            On Error Resume Next
            Set oQt = oLo.QueryTable
            On Error GoTo 0
            If Not oQt Is Nothing Then
                oQt.Refresh False
            End If
    For Each oSh In Worksheets
        For Each oPt In oSh.PivotTables
End Sub


Have a question, comment or suggestion? Then please use this form.

If your question is not directly related to this web page, but rather a more general "How do I do this" Excel question, then I advise you to ask your question here:

Please enter your name (required):

Your e-mail address (optional but if you want me to respond it helps!; will not be shown, nor be used to send you unsolicited information):

Your request or comment:

To post VBA code in your comment, use [VB] tags, like this: [VB]Code goes here[/VB].