0

I am running an Excel VBA macro from a workbook macroWb which:

  1. Opens an Excel Workbook wb(k);
  2. Copies some cells from that workbook to macroWb;
  3. Executes some fairly basic Excel commands (formatting, assigning values to cells, etc.) within the workbook macroWb;
  4. Closes wb(k);
  5. Repeats 1-4 for wb(k+1).

Letting WBs = {wb(1),...,wb(n)}, it seems that when I add further workbooks to WBs Excel ends up crashing. But then, if you ran the macro at another time it doesn't crash anymore - e.g. yesterday evening the macro was crashing, then I ran it this morning with the same set WBs as yesterday and it worked fine; I then added 3 new workbooks to WBs and it crashed again.

The crash does not seem related to any particular wb(k) as I have tested for that.

The crash details are as follows:

[...]
Fault Module Name:          StackHash_f2b6
Fault Module Version:       0.0.0.0
[...]
Exception Code:             c000041d
Exception Offset:           74384f69
[...]
Additional Information 1:   f2b6
Additional Information 2:   f2b6a6f8ea78ee3ad1bda3596b78feb6
Additional Information 3:   7b01
Additional Information 4:   7b010e90eab9e4895f15c0f6ba536eb5

Any idea of what might be causing this?

Community
  • 1
  • 1
Daneel Olivaw
  • 2,077
  • 4
  • 15
  • 23
  • 2
    Can you try and put some delay between workbooks? It looks like a time competition issue. – FDavidov Nov 09 '16 at 11:47
  • This seemed to work for a moment (I ran it with a 5 second lag before opening a new `wb(k)`) but when I added further workbooks to `WBs` it crashed again (I also tried with 10 seconds, same issue). – Daneel Olivaw Nov 09 '16 at 19:08
  • 1
    OK. We need to split the possibilities into two: First, try to manually open many files (there is a limit, at OS level) to the number of open files you can have. Try at least the same number of files that caused the crash in the last attempt. If no crash takes place, try running the process in DEBUG mode with breakpoint just before opening a new file (again, run it with enough files to get a crash in automatic mode). Post your results here and we'll continue from there. – FDavidov Nov 10 '16 at 05:44
  • I have had to modify the code for other reasons, as a consequence this crash might not be happening any longer. – Daneel Olivaw Nov 14 '16 at 10:44
  • Great, and thanks for up-voting my comment. – FDavidov Nov 14 '16 at 10:59
  • Well, the crash still happens. I tried what you advised me to do and, indeed, when I ran the program in debug mode with the break point located just before opening a new file, I was able to execute the whole program without crash. Any ideas on how I could solve the issue with this in mind? – Daneel Olivaw Nov 15 '16 at 18:34
  • Too long for a comment so I'll present to you my thoughts as an answer. – FDavidov Nov 16 '16 at 05:31

3 Answers3

1

It very much looks as a time competition issue. There is an apparent difference between having a wait before opening a new file and having a breakpoint at the same location when running with debugger. My guess is that the breakpoint does not halt the sub-process of closing files whereas the wait does.

[If your WAIT was not at the same location as the breakpoint, I'd suggest you to move it there and retry]

What I would try is:

  1. I'm assuming that the issue is related to the closing and opening of files; the issue is not caused from the number of files open (I worked in the past having perhaps 20 excel files open at the same time), but by the processes of closing and open; to test this theory, I would disable the file close part and leave files open (my recollection is that you would get the crash just above 10 files, so it should be easy and quick to test);

  2. If the result of "1" is no crash, I would search for a mechanism (event?) that would be fired as soon as the file-close process completes, and only then attempt to open the next file;

  3. If the result of "1" is yes crash... post the relevant section of your code and we'll see if there is any change that can be suggested.

This is indeed an interesting case!!!

FDavidov
  • 3,505
  • 6
  • 23
  • 59
  • Thank you for the additional tips. I tried point 1 above but the program has kept crashing. Nonetheless, inserting an `vbOk`-type `MsgBox` just before the file opening line prevents the crash (at each loop, I have to click on "Ok" to allow the program to resume execution). – Daneel Olivaw Nov 16 '16 at 09:52
  • 1
    If you feel like doing one more test, instead of vbOK message box, open a simple box and create for it a timer of, say, 5 secs, after which the box will auto-dismiss. This may preserve the wellbeing of your finger (i.e. no "click" needed). – FDavidov Nov 16 '16 at 09:57
0

Following @FDavidov advice, I ended up finding a (rather random) solution to this issue, which consists on popping up a message box that automatically closes after a specified amount of time just before opening a new file; surprisingly, the PopUp does not even seem to pause the program, lines following the PopUp execution line keep being executed while the PopUp is open.

Specifically, the PopUp code - credits to @Orphid, see his answer in the following thread - is the following:

Sub subClosingPopUp(PauseTime As Integer, Message As String, Title As String)

Dim WScriptShell As Object
Dim ConfigString As String

Set WScriptShell = CreateObject("WScript.Shell")
ConfigString = "mshta.exe vbscript:close(CreateObject(""WScript.Shell"")." & _
               "Popup(""" & Message & """," & PauseTime & ",""" & Title & """))"

WScriptShell.Run ConfigString

End Sub

The end result is then:

Sub Main()

Dim PauseTime as Integer
Dim Message as String
Dim Title as String
Dim wbk as String
Dim wb as Workbook

'Code

PauseTime = ...
Message = ...
Title = ...

'Code

For k = 1 to n
    '[Code]
    wbk = ...
    Call subClosingPopUp(PauseTime, Message, Title)
    Set wb = Workbooks.Open(wbk)
    '[Code]
Next k

'Code

End Sub
Community
  • 1
  • 1
Daneel Olivaw
  • 2,077
  • 4
  • 15
  • 23
0

I encountered this same problem happening repetitively. It turned out the problem was to do with faulty RAM in the computer. The same issue did not occur on other computers, and we are now replacing the faulty RAM.