Different DLLs loaded depending on ini file location

[colemar]

Well, I wonder whether this is a bug or a feature or whatever...

I am running SABnzbd on Windows XP behind a corporate http(s) Microsoft ISA proxy.

Since the proxy allows to CONNECT to port 443 a 563 of external hosts, I can use Proxifier (http://www.proxifier.com/) toghether with a SSL nntp account on eu.secure.news.astraweb.com:443.
This setup works well with NewsBin.

This setup works well with SABnzbd when using the ini file located in the user profile, i.e. "C:\Documents and Settings\Administrator\Local Settings\Application Data\sabnzbd\sabnzbd.ini".

Unexpectedly, it does not work when using an identical ini file located in "C:\Program Files\SABnzbd\".
It does not connect to the remote server, and Proxifier reports no connections and no tentative connections.

It does not matter whether the ini file is explicitly assigned with the -f switch or it is automatically located.

The log file reports lots of
2009-01-28 16:03:40,703::ERROR::[newswrapper] Failed to connect: (10060, 'Operation timed out') [email protected]:443
which is to be expected when the remote server is not reachable.

Using tlist command (Microsoft (R) Windows NT (TM) Version 3.51 TLIST, I believe it is from the Windows Server Resource Kit) I can see that when running from the user profile the process SABnzbd.exe loads some additional dinamic library files:
uxtheme.dll
MSCTF.dll
netapi32.dll
appHelp.dll
CLBCATQ.DLL
COMRes.dll
iertutil.dll
urlmon.dll
PrxDrvPE.dll

Those 9 DLLs are not loaded when running from the program directory.

PrxDrvPE.dll does make the difference here, because that is the thing that redirects network calls to Proxifier.

The bottom line is that the availability of a ini file in the user profile seems to trigger a very different code path in SABnzbd.

[shypike]

First of all, I'm not aware that any of these DLL-s are invoked by SABnzbd.
If so, it is done by the runtime libraries of the Python interpreter we use.

I suppose PrxDrvPE.dll is part of Proxifier, but obviously SABnzbd doesn't activitely
invoke that program. Why should it?
How is the Proxifier solution supposed to work?
Does it intercept all TCP/IP traffic, does it do some clever wrapping of  programs?

Under which user account does the program run?
Does it have write access to c:\program files\SABnzbd ?
Do you start it from an interactive session of as a service or scheduled task?


BTW: it is a very interesting experiment.

[colemar]

Sorry, it turns out that the problem it's not the position of the ini file.
Instead the following setting makes the difference:

auto_browser = 1
works (loads the additional DLLs including PrxDrvPE.dll)

auto_browser = 0
does not work (does not load the additional DLLs)

Therefore it is not possible to run "SABnzbd.exe -d" because then it assumes auto_browser = 0 and writes the ini file accordingly.
What I would like to accomplish is to run "SABnzbd.exe -d" from a scheduled task before any user logs in.

I don't know the inner workings of Proxifier, I suppose it somehow intercepts calls at the winsock level. Netstat command shows that the proxified application connects to local address 127.0.0.1 instead to the remote host, and in turn Proxifier.exe connects to the corporate proxy.
I can say that Proxifier needs only the name of the executable (SABnzbd.exe), and of course specification for the proxy to use.
I attach a png image file showing the Proxifier config window:

[shypike]

I have no idea.
What -b1 does is just launch the browser.
I have no idea why this would properly trigger Proxifier.

Maybe I don't understand the issue.
Are you trying to route the NNTP traffic or the Web interface traffic through Proxifier.
Or maybe both?

[colemar]

I'm trying to route only nntp traffic.

What about executing "SABnzbd -d -b1" from a logged on user?
Would it run the browser?

What about executing "SABnzbd -d -b1" from the scheduler with no user logged on?
Would it at least TRY to run the browser (and hence somehow trigger Proxifier)?
I suppose then that I should run Proxifier in the NT AUTHORITY\SYSTEM context before SABnzbd.

I am going to test this and maybe ask the Proxifier support about this issue.

[colemar]

Just an update.

Even when Proxifier is not running, SABnzbd loads additional DLLs depending on -b setting.

"SABnzbd.exe -b1" loads the following 8 additional DLLs:

uxtheme.dll
MSCTF.dll
netapi32.dll
appHelp.dll
CLBCATQ.DLL
COMRes.dll
iertutil.dll
urlmon.dll

Perhaps then the Phyton runtime routes the network traffic to/from one of those.
netapi32.dll and iertutil.dll (Run time utility for Internet Explorer) sound as good candidates.

[colemar]

Well, how cool is this?

Launched "C:\Program Files\Proxifier PE\Proxifier.exe"  from the scheduler as NT AUTHORITY\SYSTEM.
Launched "C:\PROGRA~1\SABnzbd\SABnzbd.exe -b1" from the scheduler as NT AUTHORITY\SYSTEM.

And it works!
PrxDrvPE.dll is loaded and SABnzbd is happily downloading at 2 MB/s.

There is a process iexplore.exe with no window (no surprise) that can be killed without any problem.

Next test is to try this before logging on as an user.

[shypike]

-d will override -b1.
Doesn't it make sense that running in daemon mode doesn't launch a browser?

BTW: the -d option is primarily aimed at Linux systems.
For Windows the main effect is that it will not try to access the user profile
(which would not be available when run as NT AUTHORITY\SYSTEM).
So "-d"  is about the same as "-b0 -f SABDIR\sabnzbd.ini".

[colemar]

Scheduled tasks cannot be made inter-dependent, hence no way to make Proxifier start before SABnzbd.

I resorted to windows services and instsrv/srvany.

• Created a service Proxifier for Proxifier.exe
• Created a service SABnzbd for SABnzbd.exe -b1
• Made SABnzbd dependent on TcpIp and Proxifier

After reboot (and without logon) I can browse SABnzbd web interface from another host and all works well.
Downloading right now at 3200 KB/s with 10 connections to Astraweb (and Giganews as backup) .