VB6 Timers failing with Windows 7

[avfadagio]

We're at a loss here. We have a large VB6 app that has worked flawlessly for years in XP. We are now trying to run it on Windows 7. It works fine, but the VB timers randomly pause for a while and then restart by themselves. We have 4-8 timers in an app (multiple apps). The timers have different intervals, anywhere from 100 to 750. We log when we enter each timer and when it exits. They always enter and exit, but randomly, a timer (usually the same one) will not trigger for anywhere from 8 to 30 seconds later, once in a great while even longer. We have tried writing a simpler app with timers to reproduce the problem but have been unsucessful.

Any suggestions for where to look? has anyone heard of anyhting like this? We're suspecting something has changed in Win 7 because it has always worked with XP.

[Justa Lol]

welcome to the forums, avfadagio.

try reducing the amount of timers, set the timer to interval 100:

dim ticks as integer

Private Sub Timer1_Timer()
ticks = ticks + 1
Select Case ticks
Case 2
label1.caption = "200ms have passed since timer was enabled."
Case 4
label1.caption = "400ms have passed since timer was enabled."
Case 6
label1.caption = "600ms have passed since timer was enabled."
End Select
End Sub

sorry if codes are bad.. i currently don't have vb6 installed, moved on to .net.

[avfadagio]

We actually did try combining some of the timers into one, but then that timer stopped for a while and restarted. I know it appears like some sort of code issue on our part. And it must be, but it has worked flawlessly in XP for years.

The timers are not executing code too long - maybe more than the 100 msec once in a while, but like I said it will pause for 20, 30 seconds or more.

We even created a watchdog timer and checked for if one of the other timers stops executing for more than 2 seconds and if so, we disable and enable the stuck timer, and then it starts running again! It's like the timer gets lost in the Windows que for a while. CPU usage is nominal, <5% usually.

Being a large and complex program it is hard to post any sample code

[Justa Lol]

well what i would do to fix such a problem would be looking at what enables the timer, and what the timer does, even if it worked on XP. if you use "on error resume next" i suggest you remove those and actually look for errors.

i can't think of anything else at the moment. if possible, it would help if you posted some piece of code.

[avfadagio]

Thank you for your thoughts.

Ya, we're not finding anybody else with this problem, so unfortunately it must be our code somewhere. As I said, it is a large complex system so it's hard just to take out or stop pieces of it and still have it run to prove it is still failing. We've be working with VB 5 -6 since they came out so we're not beginners, but we're stumped on this one.

This program actually loads VB 6 ocx's in a VB 6 container app on the fly (I did not write that code so I am a bit fuzzy on how it is done), which may somehow be causing issues.

We will keep trying (we have to! it's our job) and I will certainly post once we resolve it.

If anyone has any other thoughts, I certainly will welcome them.

[LaVolpe]

The thing to remember about timers is that they are about the lowest priority message a window will receive (via the WM_TIMER message). Executing code & just about all messages sent from the system to your project will be processed ahead of the timer. This has the effect of a timer appearing paused/slow or skipping events.

The WM_TIMER message is a low-priority message. The GetMessage and PeekMessage functions post this message only when no other higher-priority messages are in the thread's message queue.

[avfadagio]

Yet the other timers keep going. Seems like just one quits for a while.

We are using SS... objects a lot from Threed32.ocx. I notice Win 7 says those are not supported. (not sure what that means) We will try to remove some of those and see what happens.

Is there a utility or code to show the Windows message que to see if there are other messages being stacked up ahead?

[LaVolpe]

A timer doesn't just quit. It is either so far back in the queue that it appears stalled or some other code is actually terminating the timer or resetting it. Note that changing the .Interval or .Enabled properties while a timer is running will pause/stop the timer momentarily. If .Enabled is False, then stopped.

You could play with the PeekMessage API. Though I think that only applies to posted messages not messages inserted into the queue, at higher priorities, via the SendMessage family.

Though you may have 3 or 4 timers running, maybe one or more of the other OCXs you are using has a fast timer running also? The Spy++ app that came with VB can view/log messages as they come in. It has a filter where you can restrict to viewing just WM_TIMER messages for example. By filtering those, you can determine how many timers are currently running. Each WM_TIMER message has a unique ID that refers back to the actual timer sending the message (the 3rd parameter [wParam] in that message).

Edited: A timer is assigned to a specific window or no window. Knowing that, if you want to catch/log all timer messages, you'll want to set Spy++ viewing processes vs. windows. Find the process for your project/app, then view that process' messages. Otherwise, you'll have to target specific windows to view their specific messages

[avfadagio]

We used SPYxx to display our messages. (Not an expert by any means here) Here is a snapshot of what we are seeing. It seems as if the timer message is happening, but the event does not fire. Is this possible?

In the example below, our timer that quits is timerID 787784. Notice that in the first chunk, right after the timer message, there is a paint, erasebkgrnd, etc. which is our text box flashing. But the second example shows the timer, then no paint. This corresponds with us not seeing the timer event happen.

Where do we look next?

<17560> 00130500 R ..message:0x1005 [User-defined:WM_USER+3077] lResult:00000001
<17561> 0009058C P WM_TIMER wTimerID:591244 tmprc:00000000 [wParam:0009058C lParam:00000000]
<17562> 00090298 P WM_TIMER wTimerID:590488 tmprc:00000000 [wParam:00090298 lParam:00000000]
<17563> 00090384 P WM_TIMER wTimerID:0 tmprc:6DF73DCE [wParam:00000000 lParam:6DF73DCE]
<17564> 000805FC P WM_TIMER wTimerID:525820 tmprc:00000000 [wParam:000805FC lParam:00000000]
<17565> 00130500 S ..message:0x100C [User-defined:WM_USER+3084] wParam:FFFFFFFF lParam:00000001
<17566> 00130500 R ..message:0x100C [User-defined:WM_USER+3084] lResult:00000000
<17567> 00130500 S ..message:0x1005 [User-defined:WM_USER+3077] wParam:00000000 lParam:0018F154
<17568> 00130500 R ..message:0x1005 [User-defined:WM_USER+3077] lResult:00000001
<17569> 00130500 S ..message:0x100C [User-defined:WM_USER+3084] wParam:FFFFFFFF lParam:00000001
<17570> 00130500 R ..message:0x100C [User-defined:WM_USER+3084] lResult:00000000
<17571> 00130500 S ..message:0x1005 [User-defined:WM_USER+3077] wParam:00000000 lParam:0018F158
<17572> 00130500 R ..message:0x1005 [User-defined:WM_USER+3077] lResult:00000001
<17573> 000C02F0 P WM_TIMER wTimerID:787184 tmprc:00000000 [wParam:000C02F0 lParam:00000000]
<17574> 000D01F2 P WM_PAINT hdc:00000000 [wParam:00000000 lParam:00000000]
<17575> 000D01F2 S ..WM_ERASEBKGND hdc:B4010C07 [wParam:B4010C07 lParam:00000000]
<17576> 000D01F2 R ..WM_ERASEBKGND fErased:True [lResult:00000001]
<17577> 0009057C S ..WM_CTLCOLOREDIT hdcEdit:B4010C07 hwndEdit:000D01F2 [wParam:B4010C07 lParam:000D01F2]
<17578> 0009057C R ..WM_CTLCOLOREDIT hBrush:0B100C80 [lResult:0B100C80]
<17579> 0009057C S ..WM_CTLCOLOREDIT hdcEdit:B4010C07 hwndEdit:000D01F2 [wParam:B4010C07 lParam:000D01F2]
<17580> 0009057C R ..WM_CTLCOLOREDIT hBrush:0B100C80 [lResult:0B100C80]
<17581> 00090384 P WM_TIMER wTimerID:0 tmprc:6DF73DCE [wParam:00000000 lParam:6DF73DCE]
<17582> 000A057A P WM_TIMER wTimerID:656762 tmprc:00000000 [wParam:000A057A lParam:00000000]
<17583> 000805FC P WM_TIMER wTimerID:525820 tmprc:00000000 [wParam:000805FC lParam:00000000]
<17584> 00090586 P WM_TIMER wTimerID:591238 tmprc:00000000 [wParam:00090586 lParam:00000000]
<17585> 00130500 S ..message:0x100C [User-defined:WM_USER+3084] wParam:FFFFFFFF lParam:00000001
<17586> 00130500 R ..message:0x100C [User-defined:WM_USER+3084] lResult:00000000
<17587> 00130500 S ..message:0x1005 [User-defined:WM_USER+3077] wParam:00000000 lParam:0018F154
<17588> 00130500 R ..message:0x1005 [User-defined:WM_USER+3077] lResult:00000001
<17589> 00130500 S ..message:0x100C [User-defined:WM_USER+3084] wParam:FFFFFFFF lParam:00000001
<17590> 00130500 R ..message:0x100C [User-defined:WM_USER+3084] lResult:00000000
<17591> 00130500 S ..message:0x1005 [User-defined:WM_USER+3077] wParam:00000000 lParam:0018F158
<17592> 00130500 R ..message:0x1005 [User-defined:WM_USER+3077] lResult:00000001
<17593> 00090384 P WM_TIMER wTimerID:0 tmprc:6DF73DCE [wParam:00000000 lParam:6DF73DCE]




<17482> 000805FC P WM_TIMER wTimerID:525820 tmprc:00000000 [wParam:000805FC lParam:00000000]
<17483> 00130500 S ..message:0x100C [User-defined:WM_USER+3084] wParam:FFFFFFFF lParam:00000001
<17484> 00130500 R ..message:0x100C [User-defined:WM_USER+3084] lResult:00000000
<17485> 00130500 S ..message:0x1005 [User-defined:WM_USER+3077] wParam:00000000 lParam:0018F154
<17486> 00130500 R ..message:0x1005 [User-defined:WM_USER+3077] lResult:00000001
<17487> 00130500 S ..message:0x100C [User-defined:WM_USER+3084] wParam:FFFFFFFF lParam:00000001
<17488> 00130500 R ..message:0x100C [User-defined:WM_USER+3084] lResult:00000000
<17489> 00130500 S ..message:0x1005 [User-defined:WM_USER+3077] wParam:00000000 lParam:0018F158
<17490> 00130500 R ..message:0x1005 [User-defined:WM_USER+3077] lResult:00000001
<17491> 000B05CE P WM_TIMER wTimerID:722382 tmprc:00000000 [wParam:000B05CE lParam:00000000]
<17492> 000C02F0 P WM_TIMER wTimerID:787184 tmprc:00000000 [wParam:000C02F0 lParam:00000000]
<17493> 00090384 P WM_TIMER wTimerID:0 tmprc:6DF73DCE [wParam:00000000 lParam:6DF73DCE]
<17494> 000A057A P WM_TIMER wTimerID:656762 tmprc:00000000 [wParam:000A057A lParam:00000000]
<17495> 000805FC P WM_TIMER wTimerID:525820 tmprc:00000000 [wParam:000805FC lParam:00000000]
<17496> 00090586 P WM_TIMER wTimerID:591238 tmprc:00000000 [wParam:00090586 lParam:00000000]
<17497> 00130500 S ..message:0x100C [User-defined:WM_USER+3084] wParam:FFFFFFFF lParam:00000001
<17498> 00130500 R ..message:0x100C [User-defined:WM_USER+3084] lResult:00000000
<17499> 00130500 S ..message:0x1005 [User-defined:WM_USER+3077] wParam:00000000 lParam:0018F154
<17500> 00130500 R ..message:0x1005 [User-defined:WM_USER+3077] lResult:00000001
<17501> 00130500 S ..message:0x100C [User-defined:WM_USER+3084] wParam:FFFFFFFF lParam:00000001
<17502> 00130500 R ..message:0x100C [User-defined:WM_USER+3084] lResult:00000000
<17503> 00130500 S ..message:0x1005 [User-defined:WM_USER+3077] wParam:00000000 lParam:0018F158
<17504> 00130500 R ..message:0x1005 [User-defined:WM_USER+3077] lResult:00000001
<17505> 00090384 P WM_TIMER wTimerID:0 tmprc:6DF73DCE [wParam:00000000 lParam:6DF73DCE]
<17506> 0009058C P WM_TIMER wTimerID:591244 tmprc:00000000 [wParam:0009058C lParam:00000000]
<17507> 000805FC P WM_TIMER wTimerID:525820 tmprc:00000000 [wParam:000805FC lParam:00000000]

[avfadagio]

Oops. I meant timerid is 787184.

[LaVolpe]

Are you saying that you are getting more than 1 timer event? I can't tell from the snapshot whether the timer fired twice or you ran the program twice & stopped tracking after 1st event.

In VB, while in design mode (app not compiled), any opened modal window, within the project, will block a timer event in uncompiled code. Is this the case? Do you have a modal window open (msgbox, common dialog, etc)?

Else if the timer fired twice, then your event should've fired twice. Maybe looking inside the timer event to see if it Exits sub under some condition or if error trapping is aborting the routine? Just guesses as of now.

[avfadagio]

Appreciate the help.

We were tracking continually to a log file while watching visually for the flashing textbox to stop (the symptom). Once it did I stopped tracking it and then visually searched the saved log for examples of where it worked and where it did not work. I grabbed a working snippit and a non-working snippit that I then sent in the previous message.

No messages are popping up. We are just watchin the app sit there flashing a text box.

We have a log message in our timer event that logs in and out. When the event works we always see an in and an out log. When it doesn't work, we never see an in or out log.

[avfadagio]

Still looking.

We are now on the trail of wondering if it has to do with RaiseEvents. The main app (Container) loads an ocx that has a timer that is Raising an Event in the Container app. Not sure yet, but we are commenting out code as I write this to see if that helps our issue.

[avfadagio]

Ok. Here's what we found.

First of all, we got the program down to two timers, one at 750 msec that flashes a textbox, the other at 100 msec that calls an ActiveX exe function that basically checks a few variables and returns a true/false. As it stood, the 750 msec timer would periodically stop triggering. The 100 msec timer keeps going. It's as if the 750 msec timer event was being swallowed up.

Here's what appears to 'fix' the issue. In the 100 msec timer, we change the interval from 100 to 116 and then back to 100 again every other tick. The 16 is significant because the resolution of timers is basically 15 msec so we theorize it has to be bigger than that minimum resolution. (ie changing it from 100 to 110 and back did not work). Just setting the timer interval to 116 all the time did not fix it.

So, two timers, one faster than the other, calling an ActiveX exe function MAY cause a timer event to be lost, at least on Windows 7.

We are now changing the original program to use this method on all timers that call the ActiveX exe and will see if our results are positive.

[LaVolpe]

Here's a fairly simple method of using 1 timer to do 2 different events. It is similar to that in post #2. But you can't really use a simple counter since no guarantee a timer's event will trigger exactly at its interval

1. VB's Timer is reset after midnight, so a bit of extra code added to compensate
2. Optionally can use GetTickCount API. That resets every 57 days, or so, of continuous pc up time

Option Explicit

Private Type MultiTimerStruct
    Interval As Long
    ActivateTime As Single
    ActivateDate As Date
End Type

Dim mts(0 To 1) As MultiTimerStruct

Private Sub Command1_Click()
    mts(0).Interval = 750: mts(1).Interval = 50
    mts(0).ActivateDate = Date: mts(1).ActivateDate = Date
    SetActivationTime 0: SetActivationTime 1
    Timer1.Interval = 25    ' should set it to <= smallest mts interval needed
    Timer1.Enabled = True
End Sub

Private Sub Timer1_Timer()
    
    If GetAlarmState(0) Then
        SetActivationTime 0
        Debug.Print "activated 'timer1'"
    End If
    If GetAlarmState(1) Then
        SetActivationTime 1
        Debug.Print "activated 'timer2'"
    End If

End Sub

Private Function GetAlarmState(mtsIndex As Long) As Boolean
    ' helper function to test triggers that occur just b4 or just after midnight
    If VBA.Timer >= mts(mtsIndex).ActivateTime Then
        GetAlarmState = (mts(mtsIndex).ActivateDate >= Date)
    Else
        GetAlarmState = (mts(mtsIndex).ActivateDate < Date)
    End If

End Function

Private Sub SetActivationTime(mtsIndex As Long)
    ' helper function to handle activation times that span midnight
    Const maxTime As Single = 86400!
    With mts(mtsIndex)
        .ActivateTime = VBA.Timer + (.Interval / 1000!)
        If .ActivateTime >= maxTime Then
            .ActivateTime = .ActivateTime - maxTime
            .ActivateDate = .ActivateDate + 1#
        End If
    End With
End Sub

Edited: Where you place the call to SetActivationTime, within Timer1_Timer event, can make a huge difference.

a. Placing it before calling your custom function/method could trigger another immediate event after your custom function returns & next timer message received. This can happen if your custom function takes awhile to complete

b. Placing it after calling your custom function will ensure it is not re-triggered until at least the desired interval has elapsed

[QuantPlus]

Ya, we're not finding anybody else with this problem, so unfortunately it must be our code somewhere. As I said, it is a large complex system...

I have exactly the same problem...
A 20,000 line VB6 program with about 20 timers...
That manages Algorithmic Trading via IB TWS.

On Windows 7...
One timer that fires every 2000 ms...
Just goes dead for 5 or 10 or 15 minutes...
Before eventually starting up again.

This varies a LOT from machine to machine...
On an HP Win7 laptop the problem was not noticable...
On a much faster desktop the problem became very serious.

I see you've found 2 solutions...
The first a polling kludge that most would try first...
The 2nd with the interval switching... very nice work.

Sure beats re-writing 20,000 lines of code.

[dilettante]

Some small points:

You can get wrapped around the axle by making synchronous calls to out of process components such as an ActiveX EXE class or control, see:

WM_TIMER Messages not Processed as Expected When Making Out of Process COM Calls in Visual Basic 6.0

"Windows 7" didn't really change much at all. But for those paying attention, Windows Vista changed thread and process scheduling. Not a lot of the info made available during the Vista Developer Preview is still online or downloadable, but there are some things out there yet. The Vista SDK has some, but Microsoft SDK docs are getting clumsier and clumsier to navigate anymore because of format changes forced on us by the VS Team.

Inside the Windows Vista Kernel: Part 1 is still online, and it has a little bit on the scheduling changes made for the post-2001 (XP) world. The new cycle-based scheduling might account for some of the changes you are seeing. It helps prevent processor hogs from freezing out other processes as much as in the past.

[Jacob Roman]

Instead of using timers you could just use a Do While loop with a locked framerate of 60 FPS or whatever you desire. Timers aren't realtime and can get very sluggish the more you use:

Option Explicit
 
Private Declare Function QueryPerformanceCounter Lib "kernel32" (lpPerformanceCount As Currency) As Long
Private Declare Function QueryPerformanceFrequency Lib "kernel32" (lpFrequency As Currency) As Long
Private Declare Function timeGetTime Lib "winmm.dll" () As Long
 
Private Ticks_Per_Second As Currency
Private Start_Time As Currency
Private Milliseconds As Long
Private Last_Time As Long
 
Private Get_Frames_Per_Second As Long
Private Frame_Count As Long
 
Private Running As Boolean
 
Public Function Hi_Res_Timer_Initialize() As Boolean
 
    If QueryPerformanceFrequency(Ticks_Per_Second) = 0 Then
        Hi_Res_Timer_Initialize = False
    Else
        QueryPerformanceCounter Start_Time
        Hi_Res_Timer_Initialize = True
    End If
 
End Function
 
Public Function Get_Elapsed_Time() As Single
    
    Dim Last_Time As Currency
    Dim Current_Time As Currency
    
    QueryPerformanceCounter Current_Time
    Get_Elapsed_Time = (Current_Time - Last_Time) / Ticks_Per_Second
    QueryPerformanceCounter Last_Time
    
End Function
 
Private Sub Lock_Framerate(Target_FPS As Long)
 
    Static Last_Time As Currency
    Dim Current_Time As Currency
    Dim FPS As Single
    
    Do
        QueryPerformanceCounter Current_Time
        FPS = Ticks_Per_Second / (Current_Time - Last_Time)
    Loop While (FPS > Target_FPS)
    
    QueryPerformanceCounter Last_Time
 
End Sub
 
Private Function Get_FPS() As String
 
    Frame_Count = Frame_Count + 1
        
    If Get_Elapsed_Time - Milliseconds >= 1 Then
        Get_Frames_Per_Second = Frame_Count
        Frame_Count = 0
        Milliseconds = Get_Elapsed_Time
    End If
    
    Get_FPS = "FPS: " & Get_Frames_Per_Second
 
End Function
 
Private Sub Close_Program()
 
    Running = False
    Unload Me
    End
 
End Sub
 
Private Sub Main()
    
    With Me
        .Show
        .ScaleMode = 3
        .AutoRedraw = True
        .BackColor = RGB(0, 0, 0)
    End With
 
    Running = True
    Hi_Res_Timer_Initialize
    Milliseconds = Get_Elapsed_Time
    Main_Loop
 
End Sub
 
Private Sub Main_Loop()
 
    Do While Running = True
    
        DoEvents
        Lock_Framerate 60
        
        '//Timer Code Goes Here
        Me.Caption = Get_FPS
        QueryPerformanceCounter Start_Time
        
    Loop
 
End Sub
 
Private Sub Form_Load()
    
    Main
 
End Sub
 
Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)
 
    If KeyCode = vbKeyEscape Then
        Close_Program
    End If
 
End Sub
 
Private Sub Form_Unload(Cancel As Integer)
 
    Close_Program
 
End Sub

[LaVolpe]

@Jacob. A couple things. First, a niffty idea. Now to some observations & comments

1) I'd say your solution is more of a delay routine vs. a timer routine. Timer's don't halt applications
2) Your Do Loops have negative effects depending on situations
-- drop frame rate to a low number (say 1 or 2 for example) and your app is locked until Lock_Framerate exits
-- Re-entrance
3) Using END to terminate an application is never a good idea. And to get around the use of END, some tweaking would be needed

[Jacob Roman]

It was some old code I copied and pasted from years ago o.O

[QuantPlus]

After 2 weeks...
It's clear that none of the solutions put forth by avagagio...
Resolved the problem satisfactorily...
Which = intermittent hanging up of VB6 timers.

I now have now implemented a solution...
Which results in VB6 timers working under Win7...
About as well as they worked under XP (rough precision).

SOLUTION

(1) Download the Scarms Callback Timer:

http://www.thescarms.com/vbasic/timer.aspx

(2) Replace all your VB6 timers with a CallBack Timer

(3) Include any kind of stopwatch timer with each.

(4) In the CallBack Timer event subroutine (that's triggered)...
Always check the stopwatch to see reasonable time has elapsed...
For example, at least 50% of set interval...
And once it gets in, reset all CB Timer parameters each time:

'------------------------------------------------------------
 
Private Sub Process_Event_Timer(ByVal ms As Long)
 
   If (ProcessTimer.Elapsed < INTERVAL_ProcessData / 2) Then
      Exit Sub
   End If
 
   Process_Event.interval = CLng(INTERVAL_ProcessData)
   Process_Event.Resolution = 16
   Process_Event.EventType = 1
 
   ...
 
   Code To Be Triggered 
 
   ...
 
end sub
 
'------------------------------------------------------------

For some reason this CB Timer...
Occasionally triggers at very small intervals...
And can freeze up your program somewhat...
Simply exiting when interval is tiny FIXES this very reliably.

So now I have a 20,000 VB6 program with about 10 new CB Timers...
Working "perfectly" = as well as it was running on XP...
But the timers just display data...
For anything mission critical you gotta go with right NET timer, etc

And this was the ONLY VB6 incompatibility I've seen so far...
Which I suppose is a minor miracle.

[vubvubber]

Hello everyone. I just wanted to say that I too have experienced some bugs in some of my existing VB6 applications after upgrading to Windows 7. Nothing very serious so far, luckily.

But, yes, I too noticed that my timer control no longer works. Here is what I tried that worked for me.

I just used a new timer control and this worked for me. For example, say, my existing timer control was Timer1. I just added a new timer control to my form and called it Timer2. Then, I copied and pasted any existing Timer1_Timer() event code and change any Timer1 references to use Timer2 and everything works now. You can then delete Timer1 if you want.

You can also just add a new timer control to your form, call it Timer2, and then copy the existing Timer1_Timer() event code to the Timer2_Timer() event, then delete the Timer1 control and Timer1_Timer() event and rename the new timer control to Timer1 an the new even to Timer1_Timer().

I think you understand what I am saying. I think maybe I have made this sound more confusing than it is.

I don't know why this works for me, but it does. Hope this helps.