 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
VB Forum / COM / November 2005Active 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 > 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 [quoted text clipped - 22 lines] > > 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 don't need no stinking 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 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 “bad” code as well. It’s the beautifully structured, object oriented, “good” C++ code that’s 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’s been writing the bad code, doesn’t it?" http://www.danappleman.com/index.php?p=4  SignatureKen 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 > > Just for the archives... > > [quoted text clipped - 19 lines] > "And the bad code is? > And by the way, it may be time for us to reconsider our definition of "bad" > code as well. It's the beautifully structured, object oriented, "good" C++ > code that's 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's been writing the bad code, doesn't it?" > http://www.danappleman.com/index.php?p=4 |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.