On Friday, October 6, 2000 12:00:00 AM UTC-7, Steve Feldman wrote:
In case anyone from DejaNews is browsing for answers for two common problems
that I've had the same misfortune of encountering,
here is some (hopefully) helpful information. Problem one was solved with
the help of Microsoft, but I've never seen their suggestions
in any Usenet posts. Problem two I had to solve myself, as Microsoft
couldn't help (no complaints though, their support staff was very
accomodating), and I've never seen any answers on the Usenet.

As a note, both of these solutions worked for me, but there's no guarantee
that they will work for you.
I've only tried them on Excel 2000.

PROBLEM #1

Excel hangs upon opening or closing a file.

DESCRIPTION

When opening or closing large files (usually with macros) Excel hangs. I
mean HANGS...for like...ever. Once the workbook is open,
everything runs fine, even saving is okay. When opening, it appears to hang
AFTER the file is loaded into memory, and AFTER it is
scanned for virii (if you have virus protection on your workstation), but
before you can interact with the workbook. When closing,
it immediately hangs. For myself, the problem seems to occur every 3 or 4
months. (I've had it happen 3 times)

SOLUTIONS THAT DIDN'T WORK

1) Turn off AntiVirus software (doesn't work)
2) If you are running Outlook - turn off Journaling (Tools - Journaling)
(doesn't work) Actually, Microsoft tells me that this solution only
applied to the '97 versions.

SOLUTIONS THAT DID WORK

1) Delete the contents of the Windows\Temp directory
2) Delete the Windows swap file (C:\Windows\win386.swp) (Do it from DOS
mode) and restart Windows

PROBLEM #2

Excel gives you the error "VBA6.DLL" not found whenever a VBA routine is
called.

DESCRIPTION

I've never ran into this problem on my own pc. But I distribute files to
many users, and two different users have reported this problem
to me. The problem is specific to the affected workbook, not the Excel
installation, as the file will trigger the same error on every
workstation that the file is opened on. I had the user e-mail me the problem
file, and it generated the same error.

It stems from improperly associated file libraries.

In Excel 2000, the reference for "Visual Basic For Applications" from the
VBE (Tools - References) should be
"C:\Program Files\Common Files\Microsoft Shared\VBA\VBA6\VBE6.DLL"

When checking the file library references in these naughty workbooks, the
file reference for "Visual Basic For
Applications" was incorrect! The file it pointed to was
"C:\WINDOWS\SYSTEM\MSVBVM60.DLL"

And guess what, you can't change it. Not manually, not programatically. It
is a default, unchangable reference.

I called Microsoft, and they couldn't offer a solution.

SOLUTIONS THAT DIDN'T WORK

1) Manually change the file reference for "Visual Basic For Applications" to
the proper one (can't be done)
2) Programatically change the file reference for "Visual Basic For
Applications" to the proper one (can't be done)
3) Delete the file MSVBVM60.DLL in the Windows\System folder, then open the
workbook & change the reference. (still can't change
the file reference, even though it comes back as "MISSING")
4) Punch something (doesn't work)

SOLUTIONS THAT DID WORK

I tried this, and it worked fine! It makes no sense, but it worked.

1) Rename "MSVBVM60.DLL" to "ZZZ_MSVBVM60.DLL" (in the Windows\System
folder)
2) Copy "C:\Program Files\Common Files\Microsoft Shared\VBA\VBA6\VBE6.DLL"
to the
Windows\System folder
3) Rename the copied VBE6.DLL file to MSVBVM60.DLL
4) Start Excel, and open the offending workbook. It should open fine. Check
your file
references now. The incorrect entry for the VBA library magically changes
back to
the correct file library. Makes no sense, but who's complaining?
5) Save the workbook. Exit Excel
6) Delete the copied & renamed file "C:\WINDOWS\SYSTEM\MSVBVM60.DLL"
7) Rename "ZZZ_MSVBVM60.DLL" back to "MSVBVM60.DLL" (in the Windows\System
folder)
8) Voila! the file library references are back to normal.

If anyone has any comments, or thinks that this procedure is dangerous in
any way,
please reply...

STEVE (one persistant Excel 2000 user)

Steve,

Thank heaven there is no expiration on these posts. This is the ONLY ONE I FOUND THAT RESOLVED THE VBA6.DLL PROBLEM. I have been beating on this for weeks. I even threw out my code and started over from scratch, only to have the problem return when I tried to demo the software after a solid 5 days of not seeing the error. You are a giant among men, sir. Were I of the female persuasion, I would insist on bearing your child. I'm considering asking my wife to do it. You would be my choice to represent Earth before alien worlds. In this moment, as the tears fall from my cheeks because I now see that a solid weeks worth of coding was not in vain, you are second only to Jesus Christ himself. Why this did not appear as the first article in my search should lead to the summary execution of those responsible. Seriously, dude. You saved my bacon.

BTW, I am using Office 2010 on Windows 7 x64. The msvbvm60.dll is actually in the C:\Windows\SYSWOW64 folder. Because of the Trusted Installer b.s., you also need this article to perform the procedure.

http://helpdeskgeek.com/windows-7/wi...stedinstaller/

Eternally grateful,

Ken Foster

<FWIW
For clarity.., Excel 2010[+] runs VBA7 which has nothing to do with
VBA6. Projects developed in VBA6 should run just fine, though, in Excel
2010[+] without issue. (All of my XL2003 projects do!)

The msvbvm60.dll is the runtime for VB6 (Visual Basic 6.0), and has
nothing to do with the VBA runtime component installed with MS Office
(or other apps using it as a macro language)! This component
ships/installs with Windows so apps developed with VB6 will continue to
work under Windows, and so should not be 'messed' with for any reason
whatsoever!

--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion

That's a nice theory, Garry. Can you explain then why a system that was installed originally with Windows 7 and Office 2010, and has code originally developed on it in Excel 2010, would suddenly start spitting out this error? Steve's solution is the only one I found that resolved it.

That's a nice theory, Garry. Can you explain then why a system that
was installed originally with Windows 7 and Office 2010, and has code
originally developed on it in Excel 2010, would suddenly start
spitting out this error? Steve's solution is the only one I found
that resolved it.

I suspect that an app developed in VB installed/replaced the default
version of the DLL with the one that the VB app uses. Often happens
when users migrate older software to be used on newer OSs. The best way
to tell is to see if any installers replaced the default runtime
component, and/or if you do have older app[s] installed then see if
they work properly. Then 'undo' the changes you made and see if the
older app works. If it doesn't work the 1st time but does the 2nd time
then that DLL was replaced by the app's installer.

Note that the current runtime for msvbvm60.dll is SP6 (file version
created 06/10/2009 at 5:38PM. Version# is/sb 6.0.98.15. If this isn't
what's in your SysWOW64 folder then it's not what was installed with
your OS!

--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion

On Thursday, July 17, 2014 at 11:17:09 AM UTC-7, GS wrote:
That's a nice theory, Garry. Can you explain then why a system that
was installed originally with Windows 7 and Office 2010, and has code
originally developed on it in Excel 2010, would suddenly start
spitting out this error? Steve's solution is the only one I found
that resolved it.

I suspect that an app developed in VB installed/replaced the default
version of the DLL with the one that the VB app uses. Often happens
when users migrate older software to be used on newer OSs. The best way
to tell is to see if any installers replaced the default runtime
component, and/or if you do have older app[s] installed then see if
they work properly. Then 'undo' the changes you made and see if the
older app works. If it doesn't work the 1st time but does the 2nd time
then that DLL was replaced by the app's installer.

Note that the current runtime for msvbvm60.dll is SP6 (file version
created 06/10/2009 at 5:38PM. Version# is/sb 6.0.98.15. If this isn't
what's in your SysWOW64 folder then it's not what was installed with
your OS!

--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion

I had the same problem with a brand new workbook that I had just started writing macros in today. I am using Office 2010 on a 64-bit windows install, and this was the only way that I was able to update the references in my workbook to point to something other than msvbvm60.dll. I also, didn't have a VBA6.DLL at all, but did have a VBE7.DLL. I performed the copy and rename using VBE7.DLL instead of VBE6.DLL and it worked like a champ.

On Thursday, July 17, 2014 at 11:17:09 AM UTC-7, GS wrote:
That's a nice theory, Garry. Can you explain then why a system that
was installed originally with Windows 7 and Office 2010, and has
code originally developed on it in Excel 2010, would suddenly
start spitting out this error? Steve's solution is the only one I
found that resolved it.

I suspect that an app developed in VB installed/replaced the default
version of the DLL with the one that the VB app uses. Often happens
when users migrate older software to be used on newer OSs. The best
way to tell is to see if any installers replaced the default
runtime component, and/or if you do have older app[s] installed
then see if they work properly. Then 'undo' the changes you made
and see if the older app works. If it doesn't work the 1st time but
does the 2nd time then that DLL was replaced by the app's
installer.

Note that the current runtime for msvbvm60.dll is SP6 (file version
created 06/10/2009 at 5:38PM. Version# is/sb 6.0.98.15. If this
isn't what's in your SysWOW64 folder then it's not what was
installed with your OS!

--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion

I had the same problem with a brand new workbook that I had just
started writing macros in today. I am using Office 2010 on a 64-bit
windows install, and this was the only way that I was able to update
the references in my workbook to point to something other than
msvbvm60.dll. I also, didn't have a VBA6.DLL at all, but did have a
VBE7.DLL. I performed the copy and rename using VBE7.DLL instead of
VBE6.DLL and it worked like a champ.

As of v2010 all M$ Office apps use VBA7! This has no effect on earlier
projects written with VBA6, ..they still work fine running under VBA7!

--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion