VB6: Odd DCOM problem

Maury Markowitz · Joined: 04 Oct 2007 Posts: 90

The setup:

I have a DLL library I need to call from Access clients around our network.

I created a small "stub" ActiveX EXE program with the Start Mode set to
"ActiveX Component" and "Remote Server Files" turned on. The program contains
a single object, "Proxy", which has a single function inside, which has a
single line of code. All it does it take the inputs passed to it through DCOM
and immediately call the DLL on that machine.

On the client side in Access, VBA creates two variant arrays, calls
CreateObject to make an instance of the object on the server machine, and
then calls the function. In order to ensure that both the client and the
server have the same version and registry info, just before calling
CreateObject I first run the stub application locally. One of the
side-effects of running a DCOM VB application is that it registers itself,
which is kind of nice.

The problem:

All of this code has been working fine for well over a year. Two weeks ago I
did something wrong, no idea what, and re-complied the stub and broke
compatibility. I don't know how this happened, as the code literally consists
of three lines (include Function/End Function!). Ok, whatever.

Now when I call the stub from the client application my machine, a dialog
appears on the server saying that the runtime has exited incorrectly.

However, when I run the client application on another machine, right beside
mine, it works fine.

I have explored this more widely, and it appears that about 1/2 of the
machines in the office continue to work fine, and the other half don't. Yes,
this is using the exact same client and server, I run them off the network to
be sure.

Can anyone think of a reason for this? I assume that it has something to do
with the function signatures on the client machines being different than the
server, but if that is the case why does it work on any of them? And to test
this possibility I removed all related keys from my registry and re-ran the
stub, and this did not fix the problem.

Maury

Archived from group: microsoft>public>vb>general>discussion

Ralph · Joined: 04 Oct 2007 Posts: 4148

"Maury Markowitz" wrote in
message @microsoft.com...
> The setup:
>
> I have a DLL library I need to call from Access clients around our
network.
>
> I created a small "stub" ActiveX EXE program with the Start Mode set to
> "ActiveX Component" and "Remote Server Files" turned on. The program
contains
> a single object, "Proxy", which has a single function inside, which has a
> single line of code. All it does it take the inputs passed to it through
DCOM
> and immediately call the DLL on that machine.
>
> On the client side in Access, VBA creates two variant arrays, calls
> CreateObject to make an instance of the object on the server machine, and
> then calls the function. In order to ensure that both the client and the
> server have the same version and registry info, just before calling
> CreateObject I first run the stub application locally. One of the
> side-effects of running a DCOM VB application is that it registers itself,
> which is kind of nice.
>
> The problem:
>
> All of this code has been working fine for well over a year. Two weeks ago
I
> did something wrong, no idea what, and re-complied the stub and broke
> compatibility. I don't know how this happened, as the code literally
consists
> of three lines (include Function/End Function!). Ok, whatever.
>
> Now when I call the stub from the client application my machine, a dialog
> appears on the server saying that the runtime has exited incorrectly.
>
> However, when I run the client application on another machine, right
beside
> mine, it works fine.
>
> I have explored this more widely, and it appears that about 1/2 of the
> machines in the office continue to work fine, and the other half don't.
Yes,
> this is using the exact same client and server, I run them off the network
to
> be sure.
>
> Can anyone think of a reason for this? I assume that it has something to
do
> with the function signatures on the client machines being different than
the
> server, but if that is the case why does it work on any of them? And to
test
> this possibility I removed all related keys from my registry and re-ran
the
> stub, and this did not fix the problem.
>
> Maury
>

There are various tools you might use to track down the exact cause - but
you broke compatibility. Capture the original components to your development
box, and rebuild it repairing the problem. OR create a new component.

-ralph

Maury Markowitz · Joined: 04 Oct 2007 Posts: 90

"Ralph" wrote:
> There are various tools you might use to track down the exact cause - but
> you broke compatibility. Capture the original components to your development
> box, and rebuild it repairing the problem. OR create a new component.

I can't. The application literally consists of ONE LINE of code. I have
tried every possible combination of inputs to the method that I could think
of, but it still crashes. From SOME machines.

I think I'm going to need to know more about these "various tools"!

Maury

Maury Markowitz · Joined: 04 Oct 2007 Posts: 90

Here's a question... if I move my development system onto the box in
question, and run the code in the debugger, will I be able to intercept calls
to the DCOM server?

If so, is this the obvious way to debug it?

Maury

Maury Markowitz · Joined: 04 Oct 2007 Posts: 90

"Ralph" wrote:
> OR create a new component.

So considering the size of the project, I tried this.

Exact same error!

This leads me to believe the problem has nothing to do with compatibility.
What it could be has me stumped.

Maury

Ralph · Joined: 04 Oct 2007 Posts: 4148

"Maury Markowitz" wrote in
message @microsoft.com...
> "Ralph" wrote:
> > OR create a new component.
>
> So considering the size of the project, I tried this.
>
> Exact same error!
>
> This leads me to believe the problem has nothing to do with compatibility.
> What it could be has me stumped.
>
> Maury

My answer was a bit short. The reason is that I unfortunately get annoyed
when any programmer says "I broke compatibility and now
is happening to me. How do I fix it?" You fix it
by NOT breaking compatibility. If you absolutely have to break compatibility
then BREAK it and create a new one.

Before I go any farther - commit the following to memory. Rule One, Chapter
One, Verse One, Line One, in the Book Of COM is - thou shall not break
compatibility.

When I mentioned tools I was thinking of checking for incompatibility issues
like Ken Halter's (http://www.vbsight.com/BinaryComp.htm) with, as he puts
it, "a shameless plug for my addin" link at the bottom.

Now that I'm finished scolding you, I'll address your question - Why is it
still working in some places and not in others?

I don't know. It's broke.

What is the actual error message? "the runtime has exited incorrectly" isn't
a COM error I recognize. "An API call exited abnormally" ???? However, error
msgs on servers are often different than those that appear on a client box.
What happens on the client when the call fails?

Running the Exe on the client to "register it" is not a good idea. When you
install a client, that uses a remote service, you need to include the Reg
file (vbr) that is generated by the ActiveX project. It is this file that
registers the ActiveX Server.

Also normally you also need to run Dcomcnfg (Component Services) on a client
to set up additonal settings, such as Security. Changing DCOM settings on a
Server will often not take effect until the Server is re-booted.

I suppose if you studied the Registration on working Client boxes and
compared it with non-working Clients (as well as comparing it with the tlb
and vbr) you will eventually find the problem. You might even be able to
patch it. But my best advice is either go back and repair the
incompatibility or re-issue a new component. (Try setting your compatibility
option to the original tlb and not the exe.)

hth
-ralph

Ralph · Joined: 04 Oct 2007 Posts: 4148

Oops.

I forgot you are using MSAccess as your client, so you never did a
"client-install". Try running just the new vbr on the client machines. This
should match everyone up.

-ralph

Ralph · Joined: 04 Oct 2007 Posts: 4148

Something else to consider. When you use CreateObject you are passing the
ProgID to locate COM information in the registery. You mentioned you removed
all the Keys - did you also make sure you removed the ProgID entries?

-ralph

Maury Markowitz · Joined: 04 Oct 2007 Posts: 90

"Ralph" wrote:

> Something else to consider. When you use CreateObject you are passing the
> ProgID to locate COM information in the registery. You mentioned you removed
> all the Keys - did you also make sure you removed the ProgID entries?

Basically I did a search on the name of the app and deleted anything that
appeared. Some of these were GIDs, but there were others too. But everything
in the registry should be gone.

Or is there some other set of keys that would not have the name in them
somewhere?

Maury

Maury Markowitz · Joined: 04 Oct 2007 Posts: 90

"Ralph" wrote:
> What is the actual error message? "the runtime has exited incorrectly" isn't
> a COM error I recognize.

Exactly! There is every possibility this is not a DCOM problem at all. But
there is strong evidence that this isn't the whole story.

I have now re-created the project from scratch. From _scratch_. New files,
new project, new name. Completely new everything. I then installed it on the
server machine, ran the client, and called the server. Same error.

But wait, there's more... if I take the exact same client and copy it to the
machine beside me, it works fine. Same client, same server, two different
results.

What could possibly do that? It can't be a compatibility problem, because
it's a new application on both machines. It's not a registration problem,
because I use the same methods on both machines. It's not security, because
the call clearly is getting to the server.

Maury

Schmidt · Joined: 04 Oct 2007 Posts: 806

"Maury Markowitz" schrieb im
Newsbeitrag @microsoft.com...

> I have a DLL library I need to call from Access clients
> around our network.
>
> I created a small "stub" ActiveX EXE program with the
> Start Mode set to "ActiveX Component" and
> "Remote Server Files" turned on. The program contains
> a single object, "Proxy", which has a single function inside,
> which has a single line of code.
If you would take one day of your time, to "dive into"
my free dhRPC-Tools, then your DCOM-trouble would be
over I'd say.
The tool allows RegFree COM-Calls across host-boundaries.
On the serverside you would have to deploy 4
Binaries (only an XCopy and you would be done).
E.g. into:
C:\RPCServer\Bin\...
you would have to copy 4 Files:
RPCServer.exe
dhRichClient.dll
DirectCOM.dll
sqlite35_engine.dll

and into the SubFolder:
C:\RPCServer\Bin\RPCDlls\...
you would have to copy (no registering) your own Dll
(just place your current Class from the AX-Exe inside)
MyRemote.dll

That would be all for the serverside (as said, no registering
of anything needed).
Start the RPCServer.exe

On the clientside you would have to include a
project-reference to dhRichClient into your Access-Project.
(placing dhRichClient.dll, DirectCOM.dll and sqlite35_engine.dll
inside Windows\System32\ - registering of dhRichClient.dll
is only needed on your developer-machine)
Then you could write the following into a *.bas-Module:

Private Declare Function GETINSTANCE Lib "DirectCom" _
(FName As String, ClassName As String) As Object

'ensures a public available Client-Instance of the RPC-Connection
Public Property Get GetRPC() As cRPCConnection
Static mRPC As cRPCConnection
On Error Resume Next
If mRPC Is Nothing Then
Set mRPC = GETINSTANCE("dhRichClient.dll", "cRPCConnection")

If mRPC Is Nothing Then
'ErrorMessages for not able to instantiate RPC-Connection-Object
MsgBox "Couldn't create RPC-Instance"
End If

mRPC.Host = "192.168.0.xxx" 'put your Server-IP here
mRPC.Port = 22222
mRPC.KeepAlive = True
mRPC.Compression = True 'only if you transfer larger amounts of Data

If Not mRPC.Connect() Then
'ErrorMessages for not able to connect
MsgBox "Couldn't connect to: " & mRPC.Host
Set mRPC = Nothing
End If
End If
Set GetRPC = mRPC
End Property

'And this is the local Function-Wrapper for your Remote-Function
Public Function MyRemoteCall(V1 as Variant, V2 as Variant)
Const DllName$ = "MyRemote.dll"
Const ClassName$ = "cMyRemoteClass"
Const ProcName$ = "MyRemoteProcedure"
On Error GoTo ErrorHandler

'the fourth Parameter specifies the timeout of your Call
MyRemoteCall=GetRPC.RPC(DllName, ClassName, ProcName, 5, _
V1, V2) 'your Parameterlist always comes last

Exit Function

ErrorHandler:
Err.Raise Err.Number, Err.Source, Err.Description
End Function

That'd be all you need, to do remote Calls without any (Proxy-,
Stub- or) Dll-Registration.

Here is the Download for the free Toolset (including some
more advanced Demos for studying).
www.datenhaus.de/Downloads/dhRichClientDemo.zip

Olaf

Ralph · Joined: 04 Oct 2007 Posts: 4148

"Maury Markowitz" wrote in
message @microsoft.com...
> "Ralph" wrote:
>
> > Something else to consider. When you use CreateObject you are passing
the
> > ProgID to locate COM information in the registery. You mentioned you
removed
> > all the Keys - did you also make sure you removed the ProgID entries?
>
> Basically I did a search on the name of the app and deleted anything that
> appeared. Some of these were GIDs, but there were others too. But
everything
> in the registry should be gone.
>
> Or is there some other set of keys that would not have the name in them
> somewhere?
>
> Maury

Look up the argument you passed to CreateObject(), eg "MyLibrary.MyClass".
You should find a key that contains a CLSID which is used to direct you to
the CLSID COM entry.

This shouldn't actually have anything to do with your problem. I only added
it as it can in other situations.

-ralph

Maury Markowitz · Joined: 04 Oct 2007 Posts: 90

"Ralph" wrote:
> Look up the argument you passed to CreateObject(), eg "MyLibrary.MyClass".
> You should find a key that contains a CLSID which is used to direct you to
> the CLSID COM entry.

Right, that's what I thought you meant. I removed all references to the
program in the registry on both machines and then re-registered. There is now
exactly one entry on both machines, and they both have the same classid.

Maury

Ralph · Joined: 04 Oct 2007 Posts: 4148

"Maury Markowitz" wrote in
message @microsoft.com...
> "Ralph" wrote:
> > What is the actual error message? "the runtime has exited incorrectly"
isn't
> > a COM error I recognize.
>
> Exactly! There is every possibility this is not a DCOM problem at all. But
> there is strong evidence that this isn't the whole story.
>
> I have now re-created the project from scratch. From _scratch_. New files,
> new project, new name. Completely new everything. I then installed it on
the
> server machine, ran the client, and called the server. Same error.
>
> But wait, there's more... if I take the exact same client and copy it to
the
> machine beside me, it works fine. Same client, same server, two different
> results.
>
> What could possibly do that? It can't be a compatibility problem, because
> it's a new application on both machines. It's not a registration problem,
> because I use the same methods on both machines. It's not security,
because
> the call clearly is getting to the server.
>
> Maury
>

You got me.

Try creating your own client and test it out. Follow the instructions:

How To Create a DCOM Client/Server Application by Using Visual Basic
http://support.microsoft.com/kb/266717/EN-US/

Note the link to troubleshooting...

-ralph

Replacing DCOM with...? I have a small daemon-like application that sits on a machine on our network. I'd like to have more than one of these in case the machine is down -- which happens all too often for various reasons. DCOM seems to have a SIX MINUTE timeout, so you can't jus

DCOM app suddenly doesn't work I have a "stub" application running on a data server machine. All it does is stub out a call into a COM lib so it can be called via DCOM from other machines running Access or Excel apps. It has been in use for almost two years without a single error... Ab

DCOM client reconnect An ActiveX server supports several DCOM clients. When a client does something the other clients should know about, it calls a method on the server, which raises an event on all the clients (including the one that started the sequence). Each client decides

More DCOM permissions errors I have two tiny DCOM apps in VB6 that run across our network to collect data from a particular machine. I have recently had to move the machine to a new PC. Every attempt to contact the apps on the new machine returns a 70, Permission denied. I have opene

Setup failure: DCOM user account Hello Everyone, I'm new to VB.... At the end of the installation of VB6.0, I got always a setup failure. The message is as follows: Setup unable to create: DCOM user account to register C:\Program Visual