IWProxy shutdown won't unbind properly

TS 7.3.2, Win2k8 x64, brand new servers, haven't deployed any custom code/config yet.

Experiencing an issue where the first boot of the server works fine. However, when I shut down the iwproxy service, Windows keeps the port open. 'netstat -a -b -o' shows the process owner to be 'System', with a PID that matches what iwproxy was when it was running. When I start iwproxy again, it binds to the port, but traffic is directed to the 'zombie' process so static asset requests don't work.

This occurs no matter how I restart the iwproxy, and it occurs even if I shut down all other processes first and make sure (via netstat) that nothing has an open connection to 1080. ProcessExplorer shows no zombie processes, nor any children (zombie or otherwise) of iwproxy, nor anything corresponding to the reported PID. The only way I can get Windows to release the port, is to restart the whole OS.

Windows firewall is disabled; virus scan is not port scanning; infrastructure guys can't come up with any reason why something of theirs would be interfering with that port. Changing the iwproxy port to anything else (via iw.cfg) again only works the first time, and succumbs to the same issue upon iwproxy restart.

No errors in any logs; nothing of use in the Event viewer; startup and shutdown commands both report 'success' -- basically, nothing out of the ordinary there. I can reproduce this on all of our TS servers (all in the same subnet, on the same infrastructure and config).

Bottom line, iwproxy's shutdown subroutine fails to properly unbind from the port, and I can't find any explanation anywhere. I've installed TS 7.3.2 on Win2k8/x64 before (other clients) and had no such issues, so I have an inkling that some security policy somewhere is interfering, but I'm out of ideas to track it down.

Thoughts?

Find more posts tagged with

Comments

mart2001

Have you tried running iwproxy -d to see the debug output?

Rick Poulin

Yep. If I disable 'automatic startup' on the service, then again I can see the traffic working fine the very first time. If I shut it down (no errors), then start it up again, I still get a zombie process owning the port and my new instance no longer receives any traffic. It doesn't report any problems binding to the port. 'netstat -a -b -o' shows that both the zombie [Server] and iwproxy.exe are both bound to the port, but I guess the old one has priority or something, so none of the traffic gets directed to the actual process.

Some of my colleagues say they've got a client experiencing the same issue with TS 6.7.2 on Win2k8/x86.. which further reinforces my guess that this must be a Windows security policy thing, but our network folks still can't confirm.

We've opened a support case with Autonomy to see if we can get iwproxy to somehow spit our more diagnostics.

Rick Poulin

[Update] Support came back with a fix (it works). Turns out the WerFault.exe service in 2k8 (windows error reporting) thinks that iwproxy is dying 'unexpectedly' and doesn't relinquish control of the process (I'm picturing its annoying 'check for solutions online?' popup going nowhere and hanging the process). Not sure if iwproxy could be rewritten to avoid that, but as it stands, the fix is to disable the WerFault service entirely via registry key. Remains to be seen if our sysadmins complain about that.

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\Werfault.exe" /v Debugger /t REG_SZ /d NUL /f

As I understand it, the above is basically a backdoor way to cause WerFault to terminate as soon as it starts up. That didn't give me the warm and fuzzies, but looking around the web, it appears as though Microsoft Support has provided this exact answer whenever WerFault "must be disabled due to interference with applications".

Here's one such instance I found on the tubes, supposedly coming direct from MS Support:

Resolution

If you need to ensure that Werfault.exe will never be spawned when an unhandled exception is encountered, you can choose one of the following resolution paths.

1) Create a software restriction policy (via local policy or Domain GPO) to disallow Werfault.exe for all users.

Or

2) Use Image File Executions Options to cause Werfault.exe to be executed under a non-existent debugger(NUL). Since NUL can’t be found, the process fails to launch.
(REG ADD “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\Werfault.exe” /v Debugger /t REG_SZ /d NUL /f)

Migrateduser

Although Option 2 (editing the registry) would have been the simplest and cleanest solution, it did not work with my client's environment (for whatever reason).

However, Option 1 worked just fine. Steps are as follows:

go to Start/Run..., type gpedit.msc to open the Local Group Policy Editor
go to Computer Configuration\Administrative Templates\Windows Components\Windows Error Reporting\Consent
disable Configure Default Consent.