Problem with setting up ETB_STUBLOG

, ,
1

Hi

I am having trouble with setting up stublog for the following scenario:

A PDA application is making WebService calls to a web server (ISS).
The webservice is making a Natural RPC call via the EntireX .Net Wrapper for c#.
According to the EntireX documentation, this should be using the EntireX c-stub, and tracing should be controlled by the ETB_STUBLOG environment variable.

I have sat ETB_STUBLOG=1 on the webserver, and rebooted it.

However I can’t find any trace file anywhere.

With the netstat -b command i can verify that that IIS (w3wp.exe), has a connection with the broker.
And with process explorer I can verify that the ETB_STUBLOG is set for w3wp.exe.

What is going wrong?

2

Hi Steen,

what version of the broker32.dll and what version of Windows are you using ?

3

Hi Rolf

The versions are:

  • EntireX MiniRuntime 7.2.1.50
  • Windows Server 2003 R2 Standard Edition SP2
4

When I call EntireX on the server (ACI calls or using the ETBCC), I get trace files under: My Documents\Software AG\EntireX\

5

Hhhmm,

the trace should be in C:\Documents And Settings<UserName>\My Documents\Software AG\EntireX

UserName might be Administrator, or All Users, or Default User…

To be on the safe side, you should set ETB_STUBLOG in Control Panel → System → Advanced → Environment Variables → System Variables.

BTW there is also a variable ETB_STUBLOGPATH which allows you to specify the path explicitly but I think this is only available starting with 7.3.

6

In Process Explorer from Sysinternals (now Microsoft), I can see that USERPROFILE for IIS is set to C:\Documents and Settings\Default User
but there is nothing under My Documents there.
I have also asked users, if they got anything in their Documents folder, but they don’t.

Is there anything that could prevent EntireX to create the trace files?
Like security settings or antivirus?
I have searched the eventlog, but haven’t found anything suspicious though.

I will try the ETB_STUBLOGPATH anyway.

7

Oh yes, Windows security might disable this …

That’s one of the reasons we changed the stublog location from the current working directory to the Documents folder. IIS tried to write the stublog to window/system32 …

8

OK - that does the trick!

We couldn’t figure out which user the IIS is using (well probably the default: NETWORK SERVICE but we didn’t have the time to experiment).

Instead we granted universal access for the Default User folder (C:\Documents and Settings\Default User) and after reboot of the server, the trace files were generated.

Keine Hexerei - nur Beh