FTP (v12.1.10) with Windows Firewall

Technical support and scripting issues

Moderators: Dorian (MJT support), JRL

Post Reply
jpalic
Newbie
Posts: 17
Joined: Fri Aug 01, 2008 6:32 pm

FTP (v12.1.10) with Windows Firewall

Post by jpalic » Tue Sep 06, 2011 2:45 pm

I have a script compiled using MS v12.1.10 that generates Application Errors when running on Windows XP (with up to date service packs and updates).

The issue seems to originate with an attempt to FTP through the Windows Firewall when the Firewall wants to block the connection. With Windows Firewall off or with a firewall exception for the compiled script there is no error. With the Firewall on the following occurs:

First I get:
MSUpdate Application Error
Unknown software exception 0x0eedfade occurred in application at 0x7c812afb

If I click ok to that error then I get:
Application error
Exception EIdSocketError in Msupdate at 000CA8BA
Socket error # 10054
Connection reset by peer

Looking in the application event log shows:
Event ID: 4097
The exception was c0000fd at address 7C8024F0 (kernel32!ReleaseMutex)

Clearly FTP won't work if it's blocked by the firewall so I either have to turn off the firewall or create an exception - which sidesteps the issue.

But the compiled script probably shouldn't throw an application error just because the firewall is turned on.

BTW this same script did not have this behavior when compiled under version 11.

Hope this info helps in some way,

Jim

User avatar
Marcus Tettmar
Site Admin
Posts: 7380
Joined: Thu Sep 19, 2002 3:00 pm
Location: Dorset, UK
Contact:

Post by Marcus Tettmar » Tue Sep 06, 2011 3:00 pm

What is MSUpdate?
Marcus Tettmar
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar

Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?

jpalic
Newbie
Posts: 17
Joined: Fri Aug 01, 2008 6:32 pm

Post by jpalic » Thu Sep 08, 2011 2:42 pm

MSupdate.exe is the name of the script compiled with Macro Scheduler 12.

I'm struggling to pin this down. The compiiled script is used on hundreds of systems and it doesn't error on all of them. And the exact same script code didn't error at all when compiled under v11.

On the systems that it errors on, turning Windows Firewall off does seem to "fix" the issue. But the compiled script runs fine on other systems with Windows Firewall turned on.

We've also seen a situation where the error occurs if the computer is attached with an ethernet cable to the network but using the wireless connection the error doesn't occur.

Suggestions for troubleshooting are welcome!

jpalic
Newbie
Posts: 17
Joined: Fri Aug 01, 2008 6:32 pm

Post by jpalic » Thu Sep 08, 2011 3:13 pm

Another piece of data is that, when logging the script, the error seems to be in the FTPGetDirList call. I get the START: logged but no matching END:

9/8/2011 11:22:58:250 - START: FTPGetDirList>www.onlc.com,user,secret,21,C:\ms\ftp.txt,/mssrc/,*,D

Weird thing is that the ftp.txt file actually gets created. So it appears that the FTP part of the process does work.

User avatar
Marcus Tettmar
Site Admin
Posts: 7380
Joined: Thu Sep 19, 2002 3:00 pm
Location: Dorset, UK
Contact:

Post by Marcus Tettmar » Thu Sep 08, 2011 3:17 pm

So the firewall is trying to prevent the FTP operation. Hence you need to whitelist the script in the windows firewall to allow it to perform FTP operations.
Marcus Tettmar
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar

Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?

jpalic
Newbie
Posts: 17
Joined: Fri Aug 01, 2008 6:32 pm

Post by jpalic » Fri Sep 09, 2011 1:38 pm

My point in posting was to suggest that FTP in v12 have different behavior than pre v12 and possibly would merit a closer look.

- The FTP in this script worked - Windows firewall on or off - compliled under versions of Macro Scheduler prior to v12. The script sets the FTP mode to passive which should (and used to pre v12) go through the firewall without the need for a whitelist.

- Even if the FTP won't go through the firewall in v12 without a whitelist it would seem that throwing a system level application error (Dr. Watson) when the firewall is on and FTPGetDir is attempted would not be the expected behavior.

The Dr Watson log says that the error c00000fd (stack overflow) is happening in Kernel32!ReleaseMutex which seems odd because why would a Windows system function be throwing an error?

If there is anything I could do to help figure out what is going on that causes this problem I would be happy to do it. I have added code to the script to disable the Windows firewall before the FTP calls but even with that it seems that the error still occurs at times.

Thanks for considering the input,

Jim

jpalic
Newbie
Posts: 17
Joined: Fri Aug 01, 2008 6:32 pm

Post by jpalic » Tue Sep 13, 2011 9:26 pm

I distributed an updated version of this script that uses the netsh firewall command to disable the firewall before running FTP commands. This solved the problem of the software exception 0x0eedfade occuring on the FTPGetDir command.

But the same exception occurs now - with the firewall off - when the FTPGetFile command runs against a busy FTP server. The heavier the load on the FTP server, the more computers show the error.

I'm looking for any suggestions on how to gather data that would help figure out what is happening here and how to get it not to happen.

jpalic
Newbie
Posts: 17
Joined: Fri Aug 01, 2008 6:32 pm

Post by jpalic » Thu Sep 29, 2011 3:00 pm

Just as a follow up - the resolution to this was:

I extracted the FTP functionality to a separate macro, compiled that with MacroScheduler version 10, called the v10 EXE when I need to FTP and have no more application errors as was the case when using the FTP functions in v12.

FWIW, it also seems like the v10 FTP is faster than the v12 FTP.

adroege
Automation Wizard
Posts: 438
Joined: Tue Dec 07, 2004 7:39 pm

Post by adroege » Fri Oct 14, 2011 6:59 pm

mtettmar,

Can you confirm this behavior? Should I also be worried that V12 FTP behavior is not as good as V10?


Thanks!

Post Reply
Sign up to our newsletter for free automation tips, tricks & discounts