Error: 7 Out of Memory

[skoxlien]

I hope that I can get some help on this subject. I've been searching
the internet for 3 days trying to figure out the solution to this
Error: 7 Out of Memory error and nothing I have found works.

I developed the VB6 SP6 desktop application in Windows XP Pro, SP 2.
My PC is a P4 2.79 GHz with 2 GB RAM. It is an MDI application and
I'm using a language DLL that I created myself.

Several other people in my company are trying to run this Demo/Test
application, and are getting this error, and others do not get this
error. They are all running the same version of Windows XP as I am and
all have about 504 MB of RAM.

Here is a code snippet from the beginning of my program
Global COMStatus As frmCOMStatus

Public Sub Main()
Dim i As Integer
On Error GoTo closefile

'' testcode
strErrorLogFile = App.Path & "\error.log"
intErrorLog = FreeFile
Open strErrorLogFile For Output Access Write As intErrorLog
'' testcode
'' Read any registry stuff here that should be read
'' Initialize any system global variables here
' figure out what ports are available
' Initialize the Port Control array.
'testcode THIS IS TEMPORARY! REMOVE WHEN LANGUAGES ARE IMPLMENTED
intLanguage = ENGLISH
' end testcode
Call InitLanguage
bolEvaluation = True
Load frmSplash
frmSplash.Show
DelayEvents (500)
Sleep (3000)
Call ConfigurePorts
Load mdiFullDemo
mdiFullDemo.Show
'' testcode
Set DataControls = New frmDataControls
Print #intErrorLog, "Pre COMStatus"
'' testcode
' Load the COM Status Form
Load COMStatus

As you can see I have added test messages written to a log file so I
can see where I get to. I hit the Load ComStatus, but it never
actually gets into the Form Load routine of the ComStatus child form,
because I have another test message in there as the first thing, and it
never gets written into the log file.

I am not using FM20.dll, I am not using any rich text edit boxes, and I
am not using any bound controls. I know it's not the over 512 MB of
memory problem, because the PCs this is happening on all have less than
that, but have more than enough resources left to run my small
application. The language DLL can't be the problem, because it's
created and loaded as well as used before the Load ComStatus (that's
the call to InitLanguage).

Any other information I can give that will help someone help me
troubleshoot this problem, I will be happy to provide.

Thanks in advance.

[Ken Halter]

Post by skoxlien
I hope that I can get some help on this subject. I've been searching
the internet for 3 days trying to figure out the solution to this
Error: 7 Out of Memory error and nothing I have found works.

Does the app crash at the exact same point every time? Can you tell which
procedure (better yet, which line) is raising the error? If the app crashes
immediately, as soon as it's launched, you may be able to troubleshoot
things better if you start in Sub Main instead of a form.

Use conditional compilation to add a ton (or more) of debug code that writes
to a log so you can see exactly when the crash occurs.

Here's the contents of a module I include when I want this kind of thing...
'=======================
Option Explicit

#If DEBUGGING = 1 Then 'include/exclude this entire module

Public gsLogPath As String
Public gbLog2File As Boolean
Public gbOverWriteFirst As Boolean

Public Sub DebugPrint(ParamArray LogData())
'You set this stuff up.
Const LOG_PATH As String = "C:\Tam\Applog.txt"
Const LOG_2_FILE As Boolean = True
Const OVER_WRITE_FIRST As Boolean = False

Static bBeenHereB4 As Boolean
Dim i As Integer
Dim iFile As Integer

If Not bBeenHereB4 Then
If Len(gsLogPath) = 0 Then
'Assume default values
gsLogPath = LOG_PATH
gbLog2File = LOG_2_FILE
gbOverWriteFirst = OVER_WRITE_FIRST
End If
End If

If gbLog2File Then
If Not bBeenHereB4 Then
If gbOverWriteFirst Then
'Overwrite file if first time here
iFile = FreeFile
Open gsLogPath For Output As iFile
Close iFile
End If
End If

'Open file
iFile = FreeFile
Open gsLogPath For Append As iFile
If Not bBeenHereB4 Then
If Not gbOverWriteFirst Then
Print #iFile, "New Log - " & String$(40, "*")
End If
End If
End If

For i = 0 To UBound(LogData)
Debug.Print LogData(i),
If gbLog2File Then
Print #iFile, LogData(i),
End If
Next
Debug.Print 'End of line

If gbLog2File Then
Print #iFile, "" 'End of line
Close iFile
End If

bBeenHereB4 = True

End Sub

#End If
'=======================

Simple to use
'=======================
Private Sub Command1_Click()
'Just wrap the debug code with conditionals so it all comes and goes at
once
#If DEBUGGING = 1 Then
DebugPrint "Running Command1_Click", Timer
#End If
'your original code here....
End Sub
'=======================

[skoxlien]

My Startup object is Main(), and not a particular form, the code
snippet I included is Main().

The app does crash at the exact same spot every time. The Splash
screen shows and goes away like it should. I can get the MDIForm to
show and can even navigate through the menus, but it won't load any of
the child forms.

Based on what is written into the error log file that I created, it
gets to the "Load COMStatus" line and never gets into the Form_Load
procedure for that form. The first line of code in the Form_Load is to
write a message out to the log file, and that line is never in the log
file. I have several other child forms that I load after this one as
well, and have tried to comment out each successive one to see if it
was only a problem with that form, but it isn't. No matter what child
form I try to load first, this error occurs. I even went so far as to
make the splash screen a child form, but that one worked fine.

I have watched the system resources, and there is no significant
increase in the CPU usage or memory.

This user has had older versions of this software working on his PC,
and I tried one of those older versions and the older version no longer
works either. I'm beginning to think this is some other problem than
with my software or install. Anyone have any thoughts outside of the
code that could cause these kinds of problems? Registry corruption?
DLL mismatch? ActiveX Control?

I will try what you suggested though to see if I can get any more
information..

Post by Ken Halter

Post by skoxlien
I hope that I can get some help on this subject. I've been searching
the internet for 3 days trying to figure out the solution to this
Error: 7 Out of Memory error and nothing I have found works.

Does the app crash at the exact same point every time? Can you tell which
procedure (better yet, which line) is raising the error? If the app crashes
immediately, as soon as it's launched, you may be able to troubleshoot
things better if you start in Sub Main instead of a form.
Use conditional compilation to add a ton (or more) of debug code that writes
to a log so you can see exactly when the crash occurs.
Here's the contents of a module I include when I want this kind of thing...
'=======================
Option Explicit
#If DEBUGGING = 1 Then 'include/exclude this entire module
Public gsLogPath As String
Public gbLog2File As Boolean
Public gbOverWriteFirst As Boolean
Public Sub DebugPrint(ParamArray LogData())
'You set this stuff up.
Const LOG_PATH As String = "C:\Tam\Applog.txt"
Const LOG_2_FILE As Boolean = True
Const OVER_WRITE_FIRST As Boolean = False
Static bBeenHereB4 As Boolean
Dim i As Integer
Dim iFile As Integer
If Not bBeenHereB4 Then
If Len(gsLogPath) = 0 Then
'Assume default values
gsLogPath = LOG_PATH
gbLog2File = LOG_2_FILE
gbOverWriteFirst = OVER_WRITE_FIRST
End If
End If
If gbLog2File Then
If Not bBeenHereB4 Then
If gbOverWriteFirst Then
'Overwrite file if first time here
iFile = FreeFile
Open gsLogPath For Output As iFile
Close iFile
End If
End If
'Open file
iFile = FreeFile
Open gsLogPath For Append As iFile
If Not bBeenHereB4 Then
If Not gbOverWriteFirst Then
Print #iFile, "New Log - " & String$(40, "*")
End If
End If
End If
For i = 0 To UBound(LogData)
Debug.Print LogData(i),
If gbLog2File Then
Print #iFile, LogData(i),
End If
Next
Debug.Print 'End of line
If gbLog2File Then
Print #iFile, "" 'End of line
Close iFile
End If
bBeenHereB4 = True
End Sub
#End If
'=======================
Simple to use
'=======================
Private Sub Command1_Click()
'Just wrap the debug code with conditionals so it all comes and goes at
once
#If DEBUGGING = 1 Then
DebugPrint "Running Command1_Click", Timer
#End If
'your original code here....
End Sub
'=======================
--
Ken Halter - MS-MVP-VB - Please keep all discussions in the groups..
In Loving Memory - http://www.vbsight.com/Remembrance.htm

[Bob O`Bob]

Post by skoxlien
As you can see I have added test messages written to a log file so I
can see where I get to. I hit the Load ComStatus, but it never
actually gets into the Form Load routine of the ComStatus child form,
because I have another test message in there as the first thing, and it
never gets written into the log file.

You do not actually know that for certain. It may be correct, but it
also might not.

Unless you close the file after every write operation, you do not know
if there were lost buffers when the app halted.

Personally, I use the INI file APIs (writeprivateprofilestring) for that
kind of investigative logging.



Bob
--

[skoxlien]

Thanks to Ken and Bob for their responses.

I implemented the debug code suggested by Ken, which is in the spirit
of Bob's suggestion to make sure the file is closed, but it yielded the
same results, I got to the Load COMStatus line, but didn't get into the
Form_Load procedure. I did glean one more small tidbit of information.
I discovered the error definitely happens in Main() and not inside the
COMStatus forms Form_Load() procedure.

I put the following debug statement in every routine's error handler
that I know gets called before the Load COMStatus line that fails.

DebugPrint Err.Number & " " & Err.Description & " " & Err.Source
_
& " " & Err.LastDllError & " Module basPortctl Procedure
ConfigurPorts", Timer

Are there any other thoughts about this problem? Could this possibly
be a hardware problem? DLL? OCX? Registry?

Post by Bob O`Bob

Post by skoxlien
As you can see I have added test messages written to a log file so I
can see where I get to. I hit the Load ComStatus, but it never
actually gets into the Form Load routine of the ComStatus child form,
because I have another test message in there as the first thing, and it
never gets written into the log file.

You do not actually know that for certain. It may be correct, but it
also might not.
Unless you close the file after every write operation, you do not know
if there were lost buffers when the app halted.
Personally, I use the INI file APIs (writeprivateprofilestring) for that
kind of investigative logging.
Bob
--

[Bob O`Bob]

Post by skoxlien
Thanks to Ken and Bob for their responses.
I implemented the debug code suggested by Ken, which is in the spirit
of Bob's suggestion to make sure the file is closed, but it yielded the
same results, I got to the Load COMStatus line, but didn't get into the
Form_Load procedure. I did glean one more small tidbit of information.
I discovered the error definitely happens in Main() and not inside the
COMStatus forms Form_Load() procedure.
I put the following debug statement in every routine's error handler
that I know gets called before the Load COMStatus line that fails.
DebugPrint Err.Number & " " & Err.Description & " " & Err.Source
_
& " " & Err.LastDllError & " Module basPortctl Procedure
ConfigurPorts", Timer
Are there any other thoughts about this problem? Could this possibly
be a hardware problem? DLL? OCX? Registry?

WHAT? Debug.Print????

You are /able/ to observe this error when running from within the VB IDE?



Bob
--

[skoxlien]

That's a function call that writes it to the debug window and a file.
There's no '.' I wish I could debug this in the IDE, unfortunately, it
only happens on select computers and those computers are not mine and
not my test PC. They are company computers that I can ocassionally try
to fix this issue, but I can't install VB 6 on them.

Post by Bob O`Bob

Post by skoxlien
Thanks to Ken and Bob for their responses.
I implemented the debug code suggested by Ken, which is in the spirit
of Bob's suggestion to make sure the file is closed, but it yielded the
same results, I got to the Load COMStatus line, but didn't get into the
Form_Load procedure. I did glean one more small tidbit of information.
I discovered the error definitely happens in Main() and not inside the
COMStatus forms Form_Load() procedure.
I put the following debug statement in every routine's error handler
that I know gets called before the Load COMStatus line that fails.
DebugPrint Err.Number & " " & Err.Description & " " & Err.Source
_
& " " & Err.LastDllError & " Module basPortctl Procedure
ConfigurPorts", Timer
Are there any other thoughts about this problem? Could this possibly
be a hardware problem? DLL? OCX? Registry?

WHAT? Debug.Print????
You are /able/ to observe this error when running from within the VB IDE?
Bob
--

[Bob O`Bob]

Post by skoxlien
That's a function call that writes it to the debug window and a file.
There's no '.'

Ah, I missed that.

Does the form it's trying to load have any activex controls on it?

How about writing a few trivial "part task tester" apps?
Like one which merely loads the same form.



Bob
--

[skoxlien]

Each of the forms that I'm trying to load has ActiveX controls on it,
except 1.

The ActiveX controls are
COMDLG32.OCX - Image controls
MCI32.OCX - Multimedia control
MSCOMCT2.OCX - Up Down control
MSCOMCTL.OCX - Progress Bar
MSCOMM32.OCX - MSComm control

I will try to write some test apps tomorrow that test each form
individually in separate projects and see where that leads me.

Post by Bob O`Bob

Post by skoxlien
That's a function call that writes it to the debug window and a file.
There's no '.'

Ah, I missed that.
Does the form it's trying to load have any activex controls on it?
How about writing a few trivial "part task tester" apps?
Like one which merely loads the same form.
Bob
--

[skoxlien]

I did as you suggested Bob, and I have found out that the child form
that has the Up/Down control on it and the child forms without ActiveX
controls will load, but the rest will not.

I also just finished trying to remove the ActiveX controls to see if
the forms would then load, and they do (no shocking surprise there).
So, I guess I can conclude that it's the ActiveX controls causing the
problems. Any suggestions on how to figure out exactly what the system
finds to be the problems with the ActiveX controls and how to fix it?

Post by skoxlien
Each of the forms that I'm trying to load has ActiveX controls on it,
except 1.
The ActiveX controls are
COMDLG32.OCX - Image controls
MCI32.OCX - Multimedia control
MSCOMCT2.OCX - Up Down control
MSCOMCTL.OCX - Progress Bar
MSCOMM32.OCX - MSComm control
I will try to write some test apps tomorrow that test each form
individually in separate projects and see where that leads me.

Post by Bob O`Bob

Post by skoxlien
That's a function call that writes it to the debug window and a file.
There's no '.'

Ah, I missed that.
Does the form it's trying to load have any activex controls on it?
How about writing a few trivial "part task tester" apps?
Like one which merely loads the same form.
Bob
--

[Ken Halter]

Post by skoxlien
I did as you suggested Bob, and I have found out that the child form
that has the Up/Down control on it and the child forms without ActiveX
controls will load, but the rest will not.
I also just finished trying to remove the ActiveX controls to see if
the forms would then load, and they do (no shocking surprise there).
So, I guess I can conclude that it's the ActiveX controls causing the
problems. Any suggestions on how to figure out exactly what the system
finds to be the problems with the ActiveX controls and how to fix it?

Post by skoxlien
Each of the forms that I'm trying to load has ActiveX controls on it,
except 1.
The ActiveX controls are
COMDLG32.OCX - Image controls
MCI32.OCX - Multimedia control

fwiw, the DLL Help Database contains an older version of MCI32.OCX than I
have installed (which is 6.84.18, time stamped 5/22/2000 instead of the
v6.0.81.69 - 6/24/1998 version the database contains). I can't remember
using that control for any projects I have... but, if its dependencies are
updated when the media player is updated (by windows update/other) that may
be the culprit.

[skoxlien]

The version for the MCI32.OCX control I'm installing is 6.0.84.18, so
that should be the latest. I will check the PCs to make sure they are
also using that version. The only dependency I see is for comcat.dll,
which I also have as part of my installation.

Post by Ken Halter

Post by skoxlien
I did as you suggested Bob, and I have found out that the child form
that has the Up/Down control on it and the child forms without ActiveX
controls will load, but the rest will not.
I also just finished trying to remove the ActiveX controls to see if
the forms would then load, and they do (no shocking surprise there).
So, I guess I can conclude that it's the ActiveX controls causing the
problems. Any suggestions on how to figure out exactly what the system
finds to be the problems with the ActiveX controls and how to fix it?

Post by skoxlien
Each of the forms that I'm trying to load has ActiveX controls on it,
except 1.
The ActiveX controls are
COMDLG32.OCX - Image controls
MCI32.OCX - Multimedia control

fwiw, the DLL Help Database contains an older version of MCI32.OCX than I
have installed (which is 6.84.18, time stamped 5/22/2000 instead of the
v6.0.81.69 - 6/24/1998 version the database contains). I can't remember
using that control for any projects I have... but, if its dependencies are
updated when the media player is updated (by windows update/other) that may
be the culprit.
--
Ken Halter - MS-MVP-VB - Please keep all discussions in the groups..
In Loving Memory - http://www.vbsight.com/Remembrance.htm

[skoxlien]

In reviewing what ActiveX controls were installed on one the trouble
PCs, it turns out the version of the MCI32.OCX version was 6.1.97.81
where I was trying to use as previously mentioned 6.0.84.18 and the
version of the MSCOMM32.OCX was 6.0.92.92 where I was using version
6.0.81.69. Once I copied these files and registered them on my test
PC, it was showing the exact same symptoms as the problem PCs. NOW the
question becomes one for me to answer as to how they got these newer
versions of these files. Thanks for the help!

Post by skoxlien
The version for the MCI32.OCX control I'm installing is 6.0.84.18, so
that should be the latest. I will check the PCs to make sure they are
also using that version. The only dependency I see is for comcat.dll,
which I also have as part of my installation.

Post by Ken Halter

Post by skoxlien
I did as you suggested Bob, and I have found out that the child form
that has the Up/Down control on it and the child forms without ActiveX
controls will load, but the rest will not.
I also just finished trying to remove the ActiveX controls to see if
the forms would then load, and they do (no shocking surprise there).
So, I guess I can conclude that it's the ActiveX controls causing the
problems. Any suggestions on how to figure out exactly what the system
finds to be the problems with the ActiveX controls and how to fix it?

Post by skoxlien
Each of the forms that I'm trying to load has ActiveX controls on it,
except 1.
The ActiveX controls are
COMDLG32.OCX - Image controls
MCI32.OCX - Multimedia control

fwiw, the DLL Help Database contains an older version of MCI32.OCX than I
have installed (which is 6.84.18, time stamped 5/22/2000 instead of the
v6.0.81.69 - 6/24/1998 version the database contains). I can't remember
using that control for any projects I have... but, if its dependencies are
updated when the media player is updated (by windows update/other) that may
be the culprit.
--
Ken Halter - MS-MVP-VB - Please keep all discussions in the groups..
In Loving Memory - http://www.vbsight.com/Remembrance.htm

[Sinna]

Post by skoxlien
In reviewing what ActiveX controls were installed on one the trouble
PCs, it turns out the version of the MCI32.OCX version was 6.1.97.81
where I was trying to use as previously mentioned 6.0.84.18 and the
version of the MSCOMM32.OCX was 6.0.92.92 where I was using version
6.0.81.69. Once I copied these files and registered them on my test
PC, it was showing the exact same symptoms as the problem PCs. NOW the
question becomes one for me to answer as to how they got these newer
versions of these files. Thanks for the help!

<snip>
Windows Update!

You can get those files on your development/build PC by downloading the
(latest?) Service Pack for Visual Studio 6.

Sinna

[skoxlien]

I don't have all of Visual Stuido, only VB 6, and I have the latest
update for that (SP 6). Those files were not included in that service
pack, or I would already have them. The versions of the 2 files that I
have listed here from the trouble computers do not even show up in the
DLL help Database. Even so, this doesn't answer the question as to how
they got them, neither have Visual Studio of any sort installed. We all
run the same company wide Windows Updater with all very similar if not
the exact same model PC from the same manufacturers.

Post by Sinna

Post by skoxlien
In reviewing what ActiveX controls were installed on one the trouble
PCs, it turns out the version of the MCI32.OCX version was 6.1.97.81
where I was trying to use as previously mentioned 6.0.84.18 and the
version of the MSCOMM32.OCX was 6.0.92.92 where I was using version
6.0.81.69. Once I copied these files and registered them on my test
PC, it was showing the exact same symptoms as the problem PCs. NOW the
question becomes one for me to answer as to how they got these newer
versions of these files. Thanks for the help!

<snip>
Windows Update!
You can get those files on your development/build PC by downloading the
(latest?) Service Pack for Visual Studio 6.
Sinna

[Robert Morley]

This is probably stuff you already know, but just to make sure....

Like you, I wasn't able to find anything on the newer versions of the
controls, but that in itself narrows it down. The most likely culprit is
some fairly new piece of software...maybe a beta version of something, or
something written in .Net, perhaps? See if anything jumps out at you on the
machines with the newer versions.

Also on the computers that had the newer versions, you may want to try
searching the entire computer for other copies of the exact same files, or
even older versions of them. If it was done by an installer, there may
still be copies of the source files in a folder somewhere, or if it was a
service pack or something similar, it should have kept a copy of the older
files. Either way, if you find any other copies, then the folder you find
them in may lead you to figure out what the source of the newer files is.

And just FYI, out of curiosity, I checked the versions on my home (WinXP) &
work (Win2K) computers, and both had the same versions that you had. Both
are kept fairly up-to-date, with regular visits to the Windows/Office Update
sites, etc., though neither of them as yet has Office 2003 or later, nor do
they have any Microsoft betas on them.


Good luck,
Rob

Post by skoxlien
I don't have all of Visual Stuido, only VB 6, and I have the latest
update for that (SP 6). Those files were not included in that service
pack, or I would already have them. The versions of the 2 files that I
have listed here from the trouble computers do not even show up in the
DLL help Database. Even so, this doesn't answer the question as to how
they got them, neither have Visual Studio of any sort installed. We all
run the same company wide Windows Updater with all very similar if not
the exact same model PC from the same manufacturers.

Post by Sinna

Post by skoxlien
In reviewing what ActiveX controls were installed on one the trouble
PCs, it turns out the version of the MCI32.OCX version was 6.1.97.81
where I was trying to use as previously mentioned 6.0.84.18 and the
version of the MSCOMM32.OCX was 6.0.92.92 where I was using version
6.0.81.69. Once I copied these files and registered them on my test
PC, it was showing the exact same symptoms as the problem PCs. NOW the
question becomes one for me to answer as to how they got these newer
versions of these files. Thanks for the help!

<snip>
Windows Update!
You can get those files on your development/build PC by downloading the
(latest?) Service Pack for Visual Studio 6.
Sinna

[Robert Morley]

Just a follow-up to that, one likely piece of software that came to mind
just after I sent my previous post is Windows Media Player 11. I *had* that
on this computer, but didn't like the new layout and a few missing features,
so reverted to 10. New versions of Messenger/Office Communicator are also
good things to check, since people are more likely to have updated those
sorts of programs on their own without waiting for company updates.


Rob

[skoxlien]

Thanks for the input Robert.

Neither use or have updated Windows Media Player. I did a bunch of
updates on my Test PC for Win XP, including IE 7, Media Player, Google
Toolbar and a bunch of it's addons, and those files were never even
installed.

Neither have any MS betas on them. The one user said that he had a
demo installed, but had removed it. I will try to do a search of their
system and see if, like you suggested, any programs left a trail to
follow. However, the other user that had this problem would not have
downloaded that particular demo.

I downloaded and looked at VB6 SP6 release and looked at the MCI32.CAB
file. The file date was in 2002, so it seems that even the SP6 update
didn't include these newer files.

I then looked at the file dates on those controls with the newer
revisions, and they were both from 2004, one was late Feb. the other
was early March. These controls were both released before the VB6 SP6
release, but were not included in SP6. I don't think .Net uses these
older ActiveX files, but I could me mistaken about that. I am pretty
sure .Net had all new controls though.

Post by Robert Morley
This is probably stuff you already know, but just to make sure....
Like you, I wasn't able to find anything on the newer versions of the
controls, but that in itself narrows it down. The most likely culprit is
some fairly new piece of software...maybe a beta version of something, or
something written in .Net, perhaps? See if anything jumps out at you on the
machines with the newer versions.
Also on the computers that had the newer versions, you may want to try
searching the entire computer for other copies of the exact same files, or
even older versions of them. If it was done by an installer, there may
still be copies of the source files in a folder somewhere, or if it was a
service pack or something similar, it should have kept a copy of the older
files. Either way, if you find any other copies, then the folder you find
them in may lead you to figure out what the source of the newer files is.
And just FYI, out of curiosity, I checked the versions on my home (WinXP) &
work (Win2K) computers, and both had the same versions that you had. Both
are kept fairly up-to-date, with regular visits to the Windows/Office Update
sites, etc., though neither of them as yet has Office 2003 or later, nor do
they have any Microsoft betas on them.
Good luck,
Rob

Post by skoxlien
I don't have all of Visual Stuido, only VB 6, and I have the latest
update for that (SP 6). Those files were not included in that service
pack, or I would already have them. The versions of the 2 files that I
have listed here from the trouble computers do not even show up in the
DLL help Database. Even so, this doesn't answer the question as to how
they got them, neither have Visual Studio of any sort installed. We all
run the same company wide Windows Updater with all very similar if not
the exact same model PC from the same manufacturers.

Post by Sinna

Post by skoxlien
In reviewing what ActiveX controls were installed on one the trouble
PCs, it turns out the version of the MCI32.OCX version was 6.1.97.81
where I was trying to use as previously mentioned 6.0.84.18 and the
version of the MSCOMM32.OCX was 6.0.92.92 where I was using version
6.0.81.69. Once I copied these files and registered them on my test
PC, it was showing the exact same symptoms as the problem PCs. NOW the
question becomes one for me to answer as to how they got these newer
versions of these files. Thanks for the help!

<snip>
Windows Update!
You can get those files on your development/build PC by downloading the
(latest?) Service Pack for Visual Studio 6.
Sinna