Continued Firewall conflicts

[NealC804]

This has been a problem for a long time and continues in 4.0 of the SDK. When my app starts I check for critical updates using the standard code as outlined in the documentation. There seems to be the ongoing problem with IsConnected() with some firewalls where my users are getting 3-5 minute delays in the app starting. I have code to allow users to bypass "background update checking" and when they do bypass, the application starts right up.

So my first question is, why is this still an issue?

Second question is, are there any samples of performing this Asynchronously in VB6 as I would have expected this to be anyways so background update checking doesn't interfere with application startup, etc.

Why is the calls such as in the documentation Synchronous at that, or is there a switch to make it async?

This is all adding up to ditching this service as it's been a detriment unfortunately. It's been a good learning experience on how to "roll your own" but these continued issues are certainly becoming troublesome to where I'm spending more time on ISUS than my apps!

[Brad_Peterson]

neal007 wrote:
This has been a problem for a long time and continues in 4.0 of the SDK. When my app starts I check for critical updates using the standard code as outlined in the documentation. There seems to be the ongoing problem with IsConnected() with some firewalls where my users are getting 3-5 minute delays in the app starting. I have code to allow users to bypass "background update checking" and when they do bypass, the application starts right up.

So my first question is, why is this still an issue?

Second question is, are there any samples of performing this Asynchronously in VB6 as I would have expected this to be anyways so background update checking doesn't interfere with application startup, etc.

Why is the calls such as in the documentation Synchronous at that, or is there a switch to make it async?

This is all adding up to ditching this service as it's been a detriment unfortunately. It's been a good learning experience on how to "roll your own" but these continued issues are certainly becoming troublesome to where I'm spending more time on ISUS than my apps!

Strange, I've never seen anything like this. If I recall, the IsConnected() has a time out setting to 2 seconds, specifically to not hang applications as it's loaded. This has bailed me out many times. (Although to me, I think I've seen it take like 3 or 4 seconds sometimes, but that's all.)

As for firewall issues, I've never had a problem where the firewall got in the way and hung an update. Because I used the Agent object directly, all firewalls treat any updates from my program as just just another communication from our main .exe file. So, if we have firewall issues, it's due the firewall not accepting communcation from our program, and not from the firewall blocking an ISUS .exe.

As for doing it asynchronously, I'm sure that can be easily rigged up in VB6. As you know, doing anything asynchronously in VB6 can be a mess, and I'm glad ISUS just gave me a simple synchronous object to work with. But I'm in your situation too, where I need it asynchronous too. So, I plan on making it asychronous through the following fashion:

1) On my main form, I'll put a timer which always checks for update status
2) I'll have the main window I'll open a second window, which will get it's own thread. I'll also keep this window hidden. In this second window, I'll have it run code to check for updates. If updates are found, it will modify some global variable or something so when the first form's timer is fired, it will notice the the variable change, and then the first form can display that new updates are available.

This should solve any problem of having an update check locking up the main window.

Anyways neal, if I'm way off on any of these, just let me know. 🙂

[NealC804]

Take a look at one of the threads my users reported this issue. There has always been a problem with Zone Alarm. Search these forums and/or the IS KB and you'll see hits. It looks like it's still not fixed.

[Brad_Peterson]

I just ran into a ZoneAlarm type problem today. The program wasn't called ZoneAlarm, but it was essentially the ZoneAlarm program with but with a name like EZ Firewall.

It ran in the background, but it didn't allow me to set permissions rules for our program or the update service. So it just blocked these programs from communicating to the internet.

So for this instance, because it didn't pop up messages with either my program or InstallShield's update programs, I'm going to blame the firewall for this particular firewall problem I just saw.

As for the fix, I had to manually run the firewall, set our program and InstallShield's programs to allow, closed the firewall, and it worked.

[KellyF]

Yes, Computer Associates package EZ Armor suite repackages the ZoneAlarm firewall. (I use it at home) Usually it'll pop up a message indicating that program X is trying to use program Y to access the internet, though you can disable these messages.

I also agree with you, I don't see how one can control a firewall blocking the outgoing packets. (WinXP SP1's firewall which implicitly trusted Windows Media and other specific apps, so malware could piggyback on those trusted apps)

KellyF

Brad Peterson wrote:
I just ran into a ZoneAlarm type problem today. The program wasn't called ZoneAlarm, but it was essentially the ZoneAlarm program with but with a name like EZ Firewall.

[NealC804]

So once again, this is a major issue and how can we prevent this from causing tremendous delays in our applications starting when using the API's to check for critical updates?

[Brad_Peterson]

neal007 wrote:
So once again, this is a major issue and how can we prevent this from causing tremendous delays in our applications starting when using the API's to check for critical updates?

I don't know how InstallShield can do anything about this. This problem is with the firewall silently blocking internet access for certain programs. The only thing I can think of is some sort of message saying "Update Service could not communicate with the server. Possible reasons include no internet connection or a firewall blocking this program."

That may help. One Update Service window returned a 404 not found message, which, is deceiving. If I recall correctly, a 404 message means the client talked to the server, and the server replied that a particular page couldn't be found. However, in this case, Update Service did NOT communicate with their server to receive a 404 Page Not Found reply. It received nothing at all because it was blocked by a firewall. But it's reporting a 404 as if it did talk to the server. It would be better to have a different error message if no server reply was received at all...and in this error message, mention the possibilities of a firewall or a lack of an internet connection.

Should I submit a mySupport bug on this? If my understanding of what 404 errors mean, then I think the Update Service window message is incorrect and needs to be changed.

[NealC804]

The point is, there should be a timeout, and a brief one. You can read the threads on my forums where people are waiting 3-7 MINUTES before the program launches due to this issue. If there was a timeout, no big deal, 2 seconds bam, program launches, no background update. However, that's not the case and this should be something the agent can work with via a timeout or something similar. What is the horrendous delay and why?

[Brad_Peterson]

Aaah yes, I noticed a timeout of about 1 minute in the Update Service. What is strange, is my code which uses the Agent object did not hang on this machine. Only an Update Service window hung for a minute. But that window could have been cancelled at any time I believe.

I'm glad I'm not running into the bug you do 🙂

[NealC804]

Brad,

Are you running any checks for critical updates on application launch? If so, what code are you using if you don't mind my asking? Here is what I do:

Option Explicit
Dim Runner As Integer
Dim strDirectory As String, intFld As Integer
Dim hwndPreviewWindow As Long, intFormCnt As Integer
Dim mDown As Boolean

Private MsX As Single, MsY As Single
Private IsFormLoaded As Boolean
Private UpdateAgent As Agent
Private UpdateCollection As Updates
Private WithEvents UpdateInstance As Update
Private UseSplitReport As Boolean
Private ISUSUpdateReady As Boolean

Private Sub CheckISUS()
    On Error Resume Next
    
    Dim allowAutoUpdate As Boolean
    allowAutoUpdate = GetSetting(App.Title, "AutoUpdate", "Enabled", True)

    If Not allowAutoUpdate Then Exit Sub

    Dim i As Integer

    If Len(ProductCode) > 3 Then
        Set UpdateAgent = New Agent

        If UpdateAgent.IsConnected Then
            Set UpdateCollection = UpdateAgent.EnumUpdates(ProductCode)

            If Not UpdateCollection Is Nothing Then

                For i = 1 To UpdateCollection.Count
                    Set UpdateInstance = UpdateCollection.Item(i)

                    If UpdateInstance.IsSoftwareUpdate Then
                    
                        If UpdateInstance.IsNextUse Then
                            If (UpdateInstance.Download(True) = True) Then
                                ISUSUpdateReady = True
                            End If
                        End If

                    End If

                Next

            End If

        End If
    End If

End Sub

[Brad_Peterson]

I used to have my code split up into nice modular portions, but I found I had less errors when I combined everything into one big function. This sub is called when the program loads:

Keep in mind that I still use ISUS 3.1

Public Sub OneStopUpdateCheck()

Dim UpdateCollection As Object
Dim pszProductCode As String

On Local Error GoTo errorhandler:
    Set UpdateAgent = New DWUpdateServiceLib.Agent
    pszProductCode = GetProductGUID
    
    If UpdateAgent.IsConnected() Then
    'If UpdateAgent.IsConnectedEx(pszProductCode) Then
        
        Set UpdateCollection = UpdateAgent.EnumUpdates(pszProductCode)
        If Not UpdateCollection Is Nothing Then
            If UpdateCollection.Count > 0 Then
                lblUpdates.Visible = False
                If MsgBox("New updates are available for " & app.Title & ".  Would you like to install them now?", vbYesNo) = vbYes Then
                    'we already know we are connected, no need to check again
                    'If (UpdateAgent.IsConnected()) Then
                    'If (UpdateAgent.IsConnectedEx(pszProductCode)) Then
                        If (UpdateAgent.AutoUpdate(pszProductCode, False)) Then
                            ' Update should now start downloading and installing. When the update
                            ' is finished, it raises UpdateAgent's OnDownloadComplete event.
                        Else
                            'i've noticed this can happen when the machine has an instance
                            'of agent.exe running in the background.  Killing that program seemed to make that
                            'work again.  But that may not be the problem.  If this happens again, please let me (Brad) know!
                            MsgBox "No automatic update is available."
                        End If
                    'End If
                Else
                    cmdAutoUpdate.Visible = True
                End If
                
            Else
                'no updates were found, so exit cleanly
            End If
        Else
            MsgBox app.Title & " was unable to check for new updates.  If this problem persists, please call Market Data Service at " & GetMarketDataPhoneNumber & "."
        End If
    End If
    lblUpdates.Visible = False
Exit Function
errorhandler:
    MsgBox "An error occurred while checking for new updates.  Error description is: " & Err.Number & " " & Err.Description
    lblUpdates.Visible = False
End Function

[NealC804]

Okay, I see you're using AutoUpdate which takes a little control out of your hands and doesn't allow the background downloading I don't think, or at least the options to control installation as its going to run without your control. The difference in what I'm doing is here, which allows for a little more granular control:

                    If UpdateInstance.IsSoftwareUpdate Then
                    
                        If UpdateInstance.IsNextUse Then
                            If (UpdateInstance.Download(True) = True) Then
                                ISUSUpdateReady = True
                            End If
                        End If

                    End If

I'm interested to hear from Noel or Chandima on this as I'm curious where the 3-7 minute stall is coming from in this implementation with a firewall conflict. Is it the "UpdateInstance.Download(True)" call?

I'm also seeing issues as reported before where I believe the OnDownloadComplete is firing which was throwing my flag "ISUSUpdateReady" to True and prompting my users that an update was available and this was happening on every run. This started with 4.0.

[Brad_Peterson]

I have been very interested at making ours do a background download. But for now, our updates are very small, so there hasn't been a pressing need to.

Is there any way you can load on the offending firewall onto your computer or a test computer so you can duplicate the problem? That way, you can at least test to see exactly where the bug occurrs, which may help you get the bug fixed quicker with InstallShield, and it may allow you to find a possible workaround.

[NealC804]

I'm wondering if simply removing the "IsConnected()" method would resolve this issue? I'd much rather just throw an error in the update check and exit/fall out of the routine than have a 3-7 minute delay due to a firewall conflict that looks like is never getting fixed.

Is the delay only in the "IsConnected()" method? Or would this still remain in subsequent methods such as getting the update collection?

[Brad_Peterson]

neal007 wrote:
I'm wondering if simply removing the "IsConnected()" method would resolve this issue? I'd much rather just throw an error in the update check and exit/fall out of the routine than have a 3-7 minute delay due to a firewall conflict that looks like is never getting fixed.

Is the delay only in the "IsConnected()" method? Or would this still remain in subsequent methods such as getting the update collection?

I highly doubt IsConnected() is the problem. I use IsConnected, and I've never run into the issue. Again, I think the issue is one of the lines of code you use that I don't.

I also think the best way to nail down the problem is to install ZoneAlarm on a test machine and test it out yourself. If I had the free time, I'd do it myself (since I run ZoneAlarm on my computer). But you have seen the issue, and I haven't.