com, Active EXE registration gives BEEP

I have a very strange problem here with an ActiveX EXE registration with
just one customer, and I desperately need some clues if anyone can help me

The EXE registers fine on our R&D machines, and on other customer machines,
but with one customer the registration process just generates a BEEP - no
error, no event log. They've tried it on 2 different machines with the same
result. The result is the same whether they double-click on it or run it
with a /RegServer command-line option.

I've checked the registry and all the expected ActiveX keys (typelib, clsid,
progid, etc) all seem to be there. However, any attempt to instantiate the
EXE results in event id 10010 "The server %1 did not register with DCOM
within the required timeout". Most of the docs talk about Terminal Services
in conjunction with this event, but that's not applicable here.

This particular EXE is always invoked by CreateObject, using the ProgID, and
the ProgID is there. Oddly, the previous release of this EXE works fine on
their machine. There are some interface differences but the EXE was built
the same way, and has the same external dependencies. We've even re-sent the
EXE in case it somehow got corrupted but the results were the same

I've never heard of anything like this before so it's difficult to know
exactly where to look. We're currently trying to get a copy of RegMon out
there to get some more diagnostics.

Tony Proctor

Just for the archives...

This was a difficult one to solve as it appeared to defy all logic. The
problem was basically a clash between the VB6.exe version and one or more
Windows 2000 patches.

We managed to write some very simple ActiveX EXE components that also
failed. The thing they all had in common was (a) they were accidentally
built with the base VB6 version, i.e. no SP level, and (b) they all had the
'Thread per Object' property set in the project.

The machines on which these failed were all W2K and had just about every
possible Microsoft-recommended patch installed.

The same ActiveX EXE components worked on all other systems (W2K without all
these patches, and non-W2K). Also, ActiveX EXE components with the normal
'Thread Pool=1' property worked everywhere.

In effect, it looked as though that early VB6 version was generating some
"iffy" code, and one of those W2K patches was causing it to fail. The
symptoms were basically that DCOM just wasn't working [Yes, it was enabled].

...hope someone else finds this useful one day

Tony Proctor



machines,
same
clsid,
Services
and
the

We don't need no stinking patches!


Hey! I can write components that fail too! ;-)

The "iffy" code is/was on the Windows side (see link below)... VB's doing
what it was told to do <g> I've had more problems that were a direct result
of Windows Update than I care to admit to. Mostly OS related problems...
like after installing Win2k/SP4 plus the half jillion security patches, it
completely wiped out my email archive and hopelessly broke Outlook
Express... which I was never able to "fix" and ended up switching the
Thunderbird for the remainer of Win2k's life on my work PC.

"And the bad code is?
And by the way, it may be time for us to reconsider our definition of ad
code as well. It the beautifully structured, object oriented, oodC++
code that giving us all huge amount of grief due to security problems
(buffer overruns, memory leaks, games with pointers, etc.). Barring use of
Win32 API calls, VB6 was remarkably immune to all of these problems. Makes
you wonder who been writing the bad code, doesn it?"
http://www.danappleman.com/index.php?p=4

--
Ken Halter - MS-MVP-VB - http://www.vbsight.com
DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm
Please keep all discussions in the groups..

Heh, you said it Ken. I totally agree!

My s/w history includes language design and implementation (i.e. compilers,
code generators, debuggers, etc), and I've always disliked C. It was a
language designed to be read by (small-) compilers rather than humans. C++
just compounds that and allows "crypto-programming".

Given that there are many more bad programmers than good ones (no offence to
anyone reading this - it's a state of mind rather than anything related to
academic qualifications), and that C/C++ are still considered the de facto
languages for serious work, it's hardly surprising that s/w in general has
such a bad name for fragility

I kind of liked the new Java/C# type languages, but Microsoft seem intent on
taking all their .Net languages completely out of the grasp of
non-professionals, and then throwing in all manner of superfluous junk like
implicit typing, linq, etc. I'm sure it keeps some language developers in
work, and gives them fuel to write ponsy research articles in esoteric
magazines <grin>

Tony Proctor



message

more
result
"bad"