Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

VB6 Run-time errors after microsoft patches and updates

30 views
Skip to first unread message

Gary

unread,
Apr 25, 2007, 7:00:01 PM4/25/07
to
HI,
We are running some VB6 automations that allow folks to take FileNet OCX
control treeview items and register them to a corporate RDBMS database
through ADO ODBC Oracle 9i. On the 14th we placed a series of new Microsoft
patches on the users PC's and all of a sudden we started getting
"FormsOutSearch - Unanticipated error: Component 'MSDATGRD.OCX' or one of its
dependencies not correctly registered: as file is missing or invalid" - or -
we get "Run-time error '339' Component 'MSADODC.OCX' or one of its
dependencies not correctly registered: a file is missing or invalid" - or -
we get "Runtime-error '713': Class not registered. You need the following
file to be installed on your machine. MSSTDFMT.dll"
As remedy we have exhausted all we know and the only thing we know that
works is to take the ghost of the machine from before the update and use it
with that user's profile for updates shut off. That is not a very good
solution so can someone help me troubleshoot what recent patches may be doing
to clobber the ADO component set? Further more what can we do to get our
indexers back to running with all the security patches applied?
I have had some responses from other groups across the internet on this so
let me start off by saying that we have the animated cursor patch isolated as
the direct culprit for this intermittent behavior. If we uninstall that
patch the thing starts working bug free. We have had viruses in the company
(not in this area) so we have opted to keep trying to get this patch on. We
have had patch patches from Microsoft, but they too are causing the same
results.
My call out is to see if anyone has this exact situation and to collaborate
the remedy with you. If you are not experiencing this please don’t respond.

Thanks

Gary McFarling
Sr. Software Engineer II
North Dakota, Workforce Safety & Insurance
701-328-6013

The Peasant

unread,
Apr 26, 2007, 2:19:22 AM4/26/07
to
I have experienced the very same message with other OCX files.
This "Unanticipated error" was caused by (we found eventually) differing
versions of the same OCX file.

This site has a good explanation of the problem (click on the link and then
down two pages to the bit about Common Controls)
http://www.angelfire.com/biz/rhaminisys/vboledll.html#FixControls

Hope this helps.
The Peasant


"Gary" <Ga...@discussions.microsoft.com> wrote in message
news:5C7B1806-A7E7-46EA...@microsoft.com...

szu...@gmail.com

unread,
Apr 26, 2007, 10:22:05 AM4/26/07
to
On Apr 25, 7:00 pm, Gary <G...@discussions.microsoft.com> wrote:
> HI,
> We are running some VB6 automations that allow folks to take FileNet OCX
> control treeview items and register them to a corporate RDBMS database
> through ADO ODBC Oracle 9i. On the 14th we placed a series of new Microsoft
> patches on the users PC's and all of a sudden we started getting
> "FormsOutSearch - Unanticipatederror: Component 'MSDATGRD.OCX' or one of its

> dependencies not correctly registered: as file is missing or invalid" - or -
> we get "Run-timeerror'339' Component 'MSADODC.OCX' or one of its

> dependencies not correctly registered: a file is missing or invalid" - or -
> we get "Runtime-error'713': Class not registered. You need the following
> file to be installed on your machine. MSSTDFMT.dll"
> As remedy we have exhausted all we know and the only thing we know that
> works is to take the ghost of the machine from before the update and use it
> with that user's profile for updates shut off. That is not a very good
> solution so can someone help me troubleshoot what recent patches may be doing
> to clobber the ADO component set? Further more what can we do to get our
> indexers back to running with all the security patches applied?
> I have had some responses from other groups across the internet on this so
> let me start off by saying that we have the animated cursor patch isolated as
> the direct culprit for this intermittent behavior. If we uninstall that
> patch the thing starts working bug free. We have had viruses in the company
> (not in this area) so we have opted to keep trying to get this patch on. We
> have had patch patches from Microsoft, but they too are causing the same
> results.
> My call out is to see if anyone has this exact situation and to collaborate
> the remedy with you. If you are not experiencing this please don't respond.
>
> Thanks
>
> Gary McFarling
> Sr. Software Engineer II
> North Dakota, Workforce Safety & Insurance
> 701-328-6013

We have about 30 tablet PCs running a VB 6 app that uses ADO to access
local SQL Express 2005 tables. Starting maybe 2 or 3 weeks ago we
started randomly getting rte 339 on MSADODC.OCX or rte 50003
(unexpected error) on application start. I'm pretty sure the error is
bogus, because simply reattempting to start the application a few
times usually eventually succeeds. Rebooting also seems to help. The
really confusing thing is that all of these tablets were created using
the same image but only maybe 20% of them are having this issue. I am
currently waiting for one of the users that gets it often enough to
make it possible for me to troubleshoot to bring me his tablet. I
will post more when/if I learn anything.

Steve Z

unread,
May 7, 2007, 6:32:30 PM5/7/07
to
> (unexpectederror) on application start. I'm pretty sure the error is

> bogus, because simply reattempting to start the application a few
> times usually eventually succeeds. Rebooting also seems to help. The
> really confusing thing is that all of these tablets were created using
> the same image but only maybe 20% of them are having this issue. I am
> currently waiting for one of the users that gets it often enough to
> make it possible for me to troubleshoot to bring me his tablet. I
> will post more when/if I learn anything.

This just keeps getting stranger. I have now looked at two tablets
and got the same result from each.
This is the scenario 90% of the time:

1. Turn on the computer. Try to start my application. Get error
50003.
2. Try a million things, INCLUDING a complete uninstall and reinstall
of the application, various debug versions, etc. Still get error
50003.
3. Reboot (Start>Shutdown>Restart). Try to start my application.
Success.

There are exceptions to this. Sometimes once I have done the warm
reboot I can no longer get the error 50003 to occur again even after a
cold start, and sometimes it will take several warm reboots to "fix"
it.
I'd think it was an OCX or DLL version mismatch, as is commonly the
cause of this error, but I think I can rule that out since rebooting
usually fixes this (for a while).
It reeks of something to do with the order or timing of the machine
boot process, but for the life of me I can't see how that would effect
my app that might not get started until an hour after the boot process
is done.
I even upped the RAM in one of the tablets to a gig. No help.
I have an error handler at the very top of the form load event for the
main form and it is not trapping this error, so it is occurring before
the first line of my code executes.
Totally baffled. Anyone have even the most far-fetched idea I'd be
more than happy to hear it.

Gary

unread,
May 7, 2007, 9:35:01 PM5/7/07
to
Just so you folks know I have enlisted Microsoft paid support on this. We
have 5 resources I think working on it and we have no idea why just yet.

Steve Z

unread,
Jun 1, 2007, 11:11:25 AM6/1/07
to
On May 7, 9:35 pm, Gary <G...@discussions.microsoft.com> wrote:
> Just so you folks know I have enlisted Microsoft paid support on this. We
> have 5 resources I think working on it and we have no idea why just yet.
>
Just for the record, we have some users that are occasionally getting
the rte 339 on MSADODC.OCX that do not have the animated cursor patch
installed.
I'm assuming that we are talking about update 925902.

The Peasant

unread,
Jun 3, 2007, 2:38:40 AM6/3/07
to
Error 339, 50003 and occasionaly others are all part of the same problem.
From our experience, you have two options
1. You work through the various versions of this OCX (I'm sure there will
be several) trying each in turn until you find the one that will work with
your system. Don't forget that when you remove an OCX version to try
another, you should also remove the associated OCA file generated when the
system extracts the code it requires.
2. Use a program like VB Powerwrap which will wrap all the code needed
inside the EXE and will therefore avoid the problems that you are
experiencing. There is a free demo prog, I believe.
www.moonlight-software.com/vbpower.htm
Good luck
The Peasant

"Steve Z" <szu...@gmail.com> wrote in message
news:1180710685.8...@w5g2000hsg.googlegroups.com...

Steve Z

unread,
Jun 3, 2007, 10:45:53 AM6/3/07
to
On Jun 3, 2:38 am, "The Peasant" <ThePeas...@nowhere.com> wrote:
> Error 339, 50003 and occasionaly others are all part of the same problem.
> From our experience, you have two options
> 1. You work through the various versions of this OCX (I'm sure there will
> be several) trying each in turn until you find the one that will work with
> your system. Don't forget that when you remove an OCX version to try
> another, you should also remove the associated OCA file generated when the
> system extracts the code it requires.
> 2. Use a program like VB Powerwrap which will wrap all the code needed
> inside the EXE and will therefore avoid the problems that you are
> experiencing. There is a free demo prog, I believe.
> www.moonlight-software.com/vbpower.htm
> Good luck
> The Peasant

The problem is that this issue is not readily reproducible, and simply
rebooting the PC or repeatedly retrying the application launch will
"fix" it.
We have a number of users that have only gotten this error once.
Others get it maybe once a week. Others once a day. Others never.
They all have the same version of this OCX, and have had this same
version since before this issue started.

0 new messages