[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Tom

4/25/2012 12:00:00 PM

We have some apps that are compile via VB5.

The executables are run on a number of in-house computers. It's used
on computers that have the VB5 development environment installed on
them. So, the app is not installed using a package, instead the
development environment provides the required run-time environment on
each machine.

These are networked computers and updates are pushed down to them from
a central authority. The system that pushes down the updates is
called BIgFix.

Two of the executables started failing last week on two computers and
we suspect a pushed OS update caused the failure.

The message from one of the executables was: "Run-time error 50003".
The mesage from the other was "Unexpected Error". They fail at
startup.

I examined System32 directory but could not find a suspicious update
of any DDL or OCX that I though could have caused the update. I am
not sure I checked correctly, but they all tended to have old modify
dates.

Here's an odd clue. If I re-compile the exe on one of the problem
computers where the failures are occuring, then this exe works. But
if I re-compile on the development machine, then the exe fails on the
problem computers.

Both the problem computers have Office installed. In general, the
development computer and these problem computers don't have the same
layered products installed.

The OS on the computers is XP 2002 SP 3
14 Answers

Dee Earley

4/25/2012 1:01:00 PM

0

On 25/04/2012 12:59, tadamsmar@yahoo.com wrote:
> We have some apps that are compile via VB5.
>
<SNIP>
>
> Two of the executables started failing last week on two computers and
> we suspect a pushed OS update caused the failure.
>
> The message from one of the executables was: "Run-time error 50003".
> The mesage from the other was "Unexpected Error". They fail at
> startup.

What are these executables doing?
If it's a runtime error, you should be able to track it down using
normal debugging techniques and error handling.

--
Deanna Earley (dee.earley@icode.co.uk)
i-Catcher Development Team
http://www.icode.co.uk...

iCode Systems

(Replies direct to my email address will be ignored.
Please reply to the group.)

Mike Williams

4/25/2012 1:35:00 PM

0

<tadamsmar@yahoo.com> wrote in message
news:196535e2-53e2-4c5a-b539-5179f8e493a8@f5g2000vby.googlegroups.com...
> The message from one of the executables was: "Run-time
> error 50003". The mesage from the other was "Unexpected
> Error". They fail at startup. I examined System32 directory
> but could not find a suspicious update of any DDL or OCX
> that I though could have caused the update.

What happens if you provide them as regfree with all the external OCXs etc
they use being in the same folder as the compiled exe, using an appropriate
SideBySide manifest? Or, for initial test purposes, what happens if you just
provide the msvbvm50.dll file in the same folder as the compiled exe,
without using a manifest at all?

Mike



ralph

4/25/2012 1:41:00 PM

0

On Wed, 25 Apr 2012 04:59:44 -0700 (PDT), "tadamsmar@yahoo.com"
<tadamsmar@yahoo.com> wrote:

>We have some apps that are compile via VB5.
>
>The executables are run on a number of in-house computers. It's used
>on computers that have the VB5 development environment installed on
>them. So, the app is not installed using a package, instead the
>development environment provides the required run-time environment on
>each machine.
>
>These are networked computers and updates are pushed down to them from
>a central authority. The system that pushes down the updates is
>called BIgFix.
>
>Two of the executables started failing last week on two computers and
>we suspect a pushed OS update caused the failure.
>
>The message from one of the executables was: "Run-time error 50003".
>The mesage from the other was "Unexpected Error". They fail at
>startup.
>
>I examined System32 directory but could not find a suspicious update
>of any DDL or OCX that I though could have caused the update. I am
>not sure I checked correctly, but they all tended to have old modify
>dates.
>
>Here's an odd clue. If I re-compile the exe on one of the problem
>computers where the failures are occuring, then this exe works. But
>if I re-compile on the development machine, then the exe fails on the
>problem computers.
>
>Both the problem computers have Office installed. In general, the
>development computer and these problem computers don't have the same
>layered products installed.
>
>The OS on the computers is XP 2002 SP 3

Long answer...

Sounds like you have already checked-out this error online and have
discovered that the reason for getting this error is because of an
incompatable version of an ActiveX control or dll. So you went looking
for missing or different versions of components. However, note that is
not simply whether the correct component is present or not, but
whether the correct version is present and *registered*.

The usual fix for this is to simply re-install the application. Sounds
like you also noticed this online as well, since you mention at the
beginning that these applications have no install package. So let me
interject that this is the prime reason that ALL VB applications
should have an install package NO matter what the target is. However,
that horse has already escaped the barn. <bg>

First, run a registery cleaner - make sure the Registery is not
corrupted on the problem machines.

For most components, Applications compiled against an earlier version
will work with latter versions. However, applications compiled against
a newer component will not work with an earlier one. Therefore, the
most probable cause, assuming the register is OK, is that "older"
version somehow got installed on the problem machines.

You could try and determine which component and replace it. However,
the simplest solution is to upgrade the problem boxes with the latest
components.

Difficult to say what those components are without more information.
But check my short answer in another post. <g>

-ralph

ralph

4/25/2012 1:49:00 PM

0

On Wed, 25 Apr 2012 04:59:44 -0700 (PDT), "tadamsmar@yahoo.com"
<tadamsmar@yahoo.com> wrote:

>We have some apps that are compile via VB5.
>
>The executables are run on a number of in-house computers. It's used
>on computers that have the VB5 development environment installed on
>them. So, the app is not installed using a package, instead the
>development environment provides the required run-time environment on
>each machine.
>
>These are networked computers and updates are pushed down to them from
>a central authority. The system that pushes down the updates is
>called BIgFix.
>
>Two of the executables started failing last week on two computers and
>we suspect a pushed OS update caused the failure.
>
>The message from one of the executables was: "Run-time error 50003".
>The mesage from the other was "Unexpected Error". They fail at
>startup.
>
>I examined System32 directory but could not find a suspicious update
>of any DDL or OCX that I though could have caused the update. I am
>not sure I checked correctly, but they all tended to have old modify
>dates.
>
>Here's an odd clue. If I re-compile the exe on one of the problem
>computers where the failures are occuring, then this exe works. But
>if I re-compile on the development machine, then the exe fails on the
>problem computers.
>
>Both the problem computers have Office installed. In general, the
>development computer and these problem computers don't have the same
>layered products installed.
>
>The OS on the computers is XP 2002 SP 3

Short answer....

The most probable cause is an incorrect version of the common controls
(Comctl32.ocx and Comdlg32.ocx) being registered. This was a major
problem for VB5 applications since MS release some 2 to 4 different
versions, and they are commonly included in a ton (highly technical
term, <g>) of diversion MS packages.

The solution is to install the latest 'n greatest of these controls,
and that is the VB6 versions. (Yes, they will work with VB5.)

http://www.microsoft.com/download/en/details.asp...

Download that package and install on the problem boxes.

-ralph

Jeff Johnson [MVP: VB]

4/25/2012 3:24:00 PM

0



wrote in message
news:196535e2-53e2-4c5a-b539-5179f8e493a8@f5g2000vby.googlegroups.com...

> The OS on the computers is XP 2002 SP 3

For future reference, there is no "XP 2002"; it's just "XP." Perhaps you're
confusing it with Office XP, which was also known as Office 2002. XP was
released in 2001, and has never been referred to with a year.

Tom

4/25/2012 3:53:00 PM

0

On Apr 25, 9:49 am, ralph <nt_consultin...@yahoo.net> wrote:
> On Wed, 25 Apr 2012 04:59:44 -0700 (PDT), "tadams...@yahoo.com"
>
>
>
>
>
> <tadams...@yahoo.com> wrote:
> >We have some apps that are compile via VB5.
>
> >The executables are run on a number of in-house computers.  It's used
> >on computers that have the VB5 development environment installed on
> >them.  So, the app is not installed using a package, instead the
> >development environment provides the required run-time environment on
> >each machine.
>
> >These are networked computers and updates are pushed down to them from
> >a central authority.  The system that pushes down the updates is
> >called BIgFix.
>
> >Two of the executables started failing last week on two computers and
> >we suspect a pushed OS update caused the failure.
>
> >The message from one of the executables was:  "Run-time error 50003".
> >The mesage from the other was "Unexpected Error".  They fail at
> >startup.
>
> >I examined System32 directory but could not find a suspicious update
> >of any DDL or OCX that I though could have caused the update.  I am
> >not sure I checked correctly, but they all tended to have old modify
> >dates.
>
> >Here's an odd clue.  If I re-compile the exe on one of the problem
> >computers where the failures are occuring, then this exe works.   But
> >if I re-compile on the development machine, then the exe fails on the
> >problem computers.
>
> >Both the problem computers have Office installed.  In general, the
> >development computer and these problem computers don't have the same
> >layered products installed.
>
> >The OS on the computers is XP 2002 SP 3
>
> Short answer....
>
> The most probable cause is an incorrect version of the common controls
> (Comctl32.ocx and Comdlg32.ocx) being registered. This was a major
> problem for VB5 applications since MS release some 2 to 4 different
> versions, and they are commonly included in a ton (highly technical
> term, <g>) of diversion MS packages.
>
> The solution is to install the latest 'n greatest of these controls,
> and that is the VB6 versions. (Yes, they will work with VB5.)
>
> http://www.microsoft.com/download/en/details.asp...
>
> Download that package and install on the problem boxes.
>
> -ralph- Hide quoted text -
>
> - Show quoted text -

Thanks!

I already had those two OCXes in a Patch directory created as a result
of earlier troubleshooting episodes of the past.

I renamed the existing ones, copied my patch versions over, rebooted
and it works!

Don't know how this happened. Last Wednesday morning we just happened
to reboot the problem machine and it came up unable to run the VB5
executables. We figured it must have been due to a network push of
something new. Maybe it was just a registry problem or something. I
guess the network could have pushed down an out of date ocx, but that
is wierd.

Also, there was another problem machine last week with the same
problem. It had a disk crash and the systems guy started with a clean
disk and installed the operating system. That one also gave 50003
when I tried to run the exe. This machine somehow healed itself over
the weekend. On Monday morning, it ran the executable OK.

I will probably never know what happened to cause this.

Tom

4/25/2012 4:09:00 PM

0

On Apr 25, 11:23 am, "Jeff Johnson" <i....@enough.spam> wrote:
> wrote in messagenews:196535e2-53e2-4c5a-b539-5179f8e493a8@f5g2000vby.googlegroups.com...
>
> > The OS on the computers is XP 2002 SP 3
>
> For future reference, there is no "XP 2002"; it's just "XP." Perhaps you're
> confusing it with Office XP, which was also known as Office 2002. XP was
> released in 2001, and has never been referred to with a year.

Really? :-)

My System Properties screen says:

Version 2002

There must be something wrong with my computer! Can I fix that with
white out? ;-)

Dee Earley

4/25/2012 4:37:00 PM

0

On 25/04/2012 16:23, Jeff Johnson wrote:
> wrote in message
> news:196535e2-53e2-4c5a-b539-5179f8e493a8@f5g2000vby.googlegroups.com...
>
>> The OS on the computers is XP 2002 SP 3
>
> For future reference, there is no "XP 2002"; it's just "XP." Perhaps
> you're confusing it with Office XP, which was also known as Office 2002.
> XP was released in 2001, and has never been referred to with a year.

Windows XP version 2002 seems to think otherwise :)
http://dl.dropbox.com/u/2931731/XP%...
(Yes I know it's Japanese but it's the first XP machine I had to hand,
another XP VM says the same)

--
Deanna Earley (dee.earley@icode.co.uk)
i-Catcher Development Team
http://www.icode.co.uk...

iCode Systems

(Replies direct to my email address will be ignored.
Please reply to the group.)

Henning

4/25/2012 5:23:00 PM

0


"Deanna Earley" <dee.earley@icode.co.uk> skrev i meddelandet
news:jn997s$h39$1@speranza.aioe.org...
> On 25/04/2012 16:23, Jeff Johnson wrote:
>> wrote in message
>> news:196535e2-53e2-4c5a-b539-5179f8e493a8@f5g2000vby.googlegroups.com...
>>
>>> The OS on the computers is XP 2002 SP 3
>>
>> For future reference, there is no "XP 2002"; it's just "XP." Perhaps
>> you're confusing it with Office XP, which was also known as Office 2002.
>> XP was released in 2001, and has never been referred to with a year.
>
> Windows XP version 2002 seems to think otherwise :)
> http://dl.dropbox.com/u/2931731/XP%...
> (Yes I know it's Japanese but it's the first XP machine I had to hand,
> another XP VM says the same)
>
> --
> Deanna Earley (dee.earley@icode.co.uk)
> i-Catcher Development Team
> http://www.icode.co.uk...
>
> iCode Systems
>
> (Replies direct to my email address will be ignored.
> Please reply to the group.)

Mine also say Microsoft Windows XP
Professional
Version 2002
Service Pack 3.

/Henning


ralph

4/25/2012 8:53:00 PM

0

On Wed, 25 Apr 2012 08:53:09 -0700 (PDT), "tadamsmar@yahoo.com"
<tadamsmar@yahoo.com> wrote:


>
>Don't know how this happened. Last Wednesday morning we just happened
>to reboot the problem machine and it came up unable to run the VB5
>executables. We figured it must have been due to a network push of
>something new. Maybe it was just a registry problem or something. I
>guess the network could have pushed down an out of date ocx, but that
>is wierd.
>
>Also, there was another problem machine last week with the same
>problem. It had a disk crash and the systems guy started with a clean
>disk and installed the operating system. That one also gave 50003
>when I tried to run the exe. This machine somehow healed itself over
>the weekend. On Monday morning, it ran the executable OK.
>
>I will probably never know what happened to cause this.

Don't know squat about how your shop is administered or configured,
but here is something you might look into ...

It is possible for ActiveX components to be registered by "User" and
not by "machine" or for "all users".

[You occasionally come across this phenomena when installing Office
products under an Administrative account with some Windows
security/permissions configurations. The product is installed, but
each user must also run an "install" to correctly register all the
components for their use.]

Since you are copying files and not installing you are trusting the
controls to be registered on "first use". Tracking exactly "Who" is
touching what, and when, may provide a clue should it happen again.

-ralph