Mature VB6 Program - Crashing on some Win10 machines

[mrgasc]

I’ve been pulling my hair out for quite a few weeks with this issue, and I’m taking a shot in the dark that someone here might have some insight.

I’m new to the forum, but I searched posts and didn’t see anything applicable. I work for a small engineering company and I have been in charge of writing/maintaining some custom codes for data acquisition for the past 18 years. The original programs were all written in VB6 and they have never been ported to anything else.

My current problem involves a usb data acquisition device, from Data Translation. The DT9804 is the specific module. We have been using this module and the same code for many years. We have never had any issues with program stability in Windows XP or Win7, but we are seeing issues under Win10 and Win11.

I have one desktop pc that runs Win10 and the program runs fine with no issues. Every other machine that I have tried it on though has issues. I’ve worked with six other pcs, five laptops and a desktop. Five of them run Win10 and one runs Win11. On all of these machines, the program will cause a full BSOD. The timing is variable, it might be two minutes, it might be 20, but it consistently occurs. The program runs with a “realtime” mode, that is constantly running acquisitions and updating the display with results. If I turn off the “realtime” mode, meaning that the program is not constantly communicating with the usb DAQ, the program will not crash.

I added a log file, that writes out positions throughout the data acquisition routine, to help me to see if one specific command causes the issue. However, that is not the case. The program will go to a BSOD at seemingly random times, not correlated to a single or even a couple of calls to the usb board.

The program nominally samples at 2500 Hz. I initially thought that there might be an issue where the usb was getting bogged down. I modified the program to allow for the user to specify the acquisition rate. If I slow the rate waaaaay down, all the way to 30 Hz, I saw some improvement. At that point, I could run the program with more consistency one most of my machines. This is not an ideal solution, obviously, and my data was bouncing around a lot more as a result of this change. However, I still had one machine that will crash. It doesn’t matter if dial the acquisition rate all the way back to 1 Hz, this machine will still crash.

All of my machines are using the same version of the driver for the USB board. All of the Win10 machines are running the same version of Win10 (Win10 Pro 21H2).

I’m happy to post a stripped down version of my code, if anyone thinks that it will help. I guess I’m just looking to see if anyone has seen issues with a mature VB6 code when moving from WinXP/7 to Win10/11. It is extra confusing to me that everything works fine on one Win10 machine. Thanks for reading the long message, any insights are appreciated.

[Eduardo-]

Hello, welcome to the forum.

I added a log file, that writes out positions throughout the data acquisition routine, to help me to see if one specific command causes the issue. However, that is not the case. The program will go to a BSOD at seemingly random times, not correlated to a single or even a couple of calls to the usb board.

That's not very clear to me, since you talk of "commands", "times" and "calls to the usb board".
I think I would be interested in knowing in what code lines, in what functions calls the crashes occur.

How do you communicate to the USB device? Maybe you could try another way (of communication).

[Eduardo-]

All of my machines are using the same version of the driver for the USB board.

I guess that it uses an specific driver for the device. Try to check if there is a newer driver from the vendor. Maybe the driver does not work fine in W10.

[mrgasc]

It's the latest version of the driver.

[jdc2000]

One other thought would be to try setting up a Virtual Machine on one of the problem Windows 10/11 computers and install Windows 7 or XP, then see if you can run the program in the VM without crashing.

[Eduardo-]

It's the latest version of the driver.

"Latest" from what year, and what Windows versions are supported by the driver?
Did you contact the vendor?

[mrgasc]

I am running a timer on my primary form:

Private Sub Timer1_Timer()

Dim AICalFacs(32, 32) As Double, Volts(32, 80000) As Double, AveVolts(32) As Double, AveEngine(32) As Double, Errormmf As Long, i As Integer

StandardAISub 0.5, 800, 2, "Differential", "None", "None", "None", AICalFacs(), Volts(), AveVolts(), AveEngine(), Errormmf
lblOutput.Caption = Format(AveVolts(0), "0.000") + "   " + Format(AveVolts(1), "0.000")
lblOutput.Refresh

End Sub

The timer calls my analog input subroutine:

Sub StandardAISub(ByVal AIPeriod As Double, _
             ByVal AIFrequency As Double, _
             ByVal NumChannels As Long, _
             ByVal ChannelType As String, _
             ByVal RawVoltageFile As String, _
             ByVal AveVoltageFile As String, _
             ByVal AveEngineFile As String, _
             AICalFacs() As Double, _
             RawVoltage() As Double, _
             AveVoltage() As Double, _
             AveEngine() As Double, _
             AIError As Long)

'alternate version made for submission to forum

    Dim cc As Double, NumScans As Long, i As Long, j As Long, AcqStartTime As Double
    Dim aa As Double, bb As Double, subtime As Double, testpath As String
    Dim pos As Integer
    
    ReDim dataBuffer(AIPeriod * AIFrequency * NumChannels) As Integer

    On Error GoTo ErrorHandler

    AbortAI = False
    AIRunning = False
           
    NumScans = AIFrequency * AIPeriod
    pos = 1: DAQLog pos
    frmMAin.DTAADC.Frequency = AIFrequency * NumChannels
    
    hbuf = AllocBuffer(0, AIFrequency * AIPeriod * NumChannels)

    frmMAin.DTAADC.Queue = hbuf
    
    pos = 12: DAQLog pos
    frmMAin.DTAADC.Config
            
    AcqStartTime = Timer()
    frmMAin.DTAADC.Start  'start subsystem
    pos = 15: DAQLog pos
    bb = Timer() - AcqStartTime
    AcqStartTime = Timer()
    AIRunning = True
    While frmMAin.DTAADC.QueueSize(OL_QUE_INPROCESS) <> 0
        If AbortAI Then
            AIRunning = False
            Exit Sub
        End If
        If Timer() - AcqStartTime > AIPeriod + 2.5 Then
            MsgBox "Acq running too long, aborting"
            Exit Sub
        End If
    Wend
    AIRunning = False
            

    Pause (0.01)
    'get buffer from Done Queue
    hbuf = frmMAin.DTAADC.Queue
    'copy data to user buffer
    CopyFromBuffer hbuf, dataBuffer(0), AIFrequency * AIPeriod * NumChannels
    FreeBuffer hbuf 'Free buffer from memory

    For i = 0 To NumChannels - 1
        AveVoltage(i) = 0
        For j = 0 To NumScans - 1
            RawVoltage(i, j) = (dataBuffer(j * NumChannels + i) * (20 / 65536) - (dataBuffer(j * NumChannels + i) < 0) * 20 - 10)
            AveVoltage(i) = AveVoltage(i) + RawVoltage(i, j)
        Next j
        AveVoltage(i) = AveVoltage(i) / NumScans
        If IsNumeric(AICalFacs(i, 1)) And IsNumeric(AICalFacs(i, 2)) Then
            AveEngine(i) = (AveVoltage(i) - AICalFacs(i, 1)) * AICalFacs(i, 2)
        End If
    Next i
    
    pos = 50: DAQLog pos
    Exit Sub

ErrorHandler:
    pos = 60: DAQLog pos + ", " + VBA.Format$(Error)
    MsgBox Error
    AIRunning = False
    Close
End Sub

I ran a trial recently where I ran the program 26 times and tracked where it crashed.
It crashed on the following commands:

Crashes: 2
frmMAin.DTAADC.Frequency = AIFrequency * NumChannels

Crashes: 2
frmMAin.DTAADC.Config

Crashes: 5
While frmMAin.DTAADC.QueueSize(OL_QUE_INPROCESS) <> 0

Crashes: 4
End of sub

Crashes: 13
Call of sub in the timer



In response to your specific question, the use of "times" in my original post does not refer to any "time" in the program. I was just making a generic, "it crashes randomly". The program could run for one minute or 20, that was what I meant by "times".

The "calls to the USB board" are those that occur in my AI code above, that start with "frmMAin.DTAADC.". These are calls to the USB A/D board. AS you can see in my list of crash points, there are three different "calls" that led to a crash that I have identified so far; frmMAin.DTAADC.Frequency, frmMAin.DTAADC.Config, frmMAin.DTAADC.QueueSize.

[mrgasc]

The driver was released April 7, 2022. Per the manufacturer;

"Device drivers for Windows 11 /10 / 8.1 / 8 (64-bit and 32-bit), Windows 7 (64-bit and 32-bit), Windows Vista (64-bit and 32-bit) and Windows XP (32-bit only). The installation program automatically installs the appropriate driver for your operating system."

As I mentioned, I confirmed that all of my Win10/11 machines are running the same version of the driver.

[mrgasc]

Good thought. I will give this a try.

[Eduardo-]

Yes, I would try to contact the manufacturer, they should probably already know about the issue.

PS: there are many things to download from there, I would try to see if the problem also happens with their own software.

[Eduardo-]

This is the specific support page: https://www.mccdaq.com/Support.aspx

[dilettante]

I guess I’m just looking to see if anyone has seen issues with a mature VB6 code when moving from WinXP/7 to Win10/11.

Odd way to view things.

Windows 7 is just a rewarmed and less secure version of Vista. It has far more in common with Windows 10 and 11 than XP.

Windows XP was a dumbed down version of Windows 2000, with additional appcompat shims added to help wean laggards off Win9x. The cartoony user interface was part of the marketing to get people to move.

It is extra confusing to me that everything works fine on one Win10 machine.

Yeah, that pretty much shoots the "Windows 10 touched me inappropriately" argument down.


I can understand your frustration, but I think you are looking in the wrong place.

If the program is the same, the driver is the same, and they were both installed the same, and it is even working on a Windows 10 machine... that doesn't leave much else.

Some differences in the hardware? Or even more likely some difference in environment: user account configuration or maybe the lower-level USB drivers this vendor's API sits on top of?

[Elroy]

What's that USB driver clean-out utility? Both times that I read through this thread, I thought about that. There's probably more than one utility to do that, but it's a utility to clean-out your USB drivers, and you can get LOTS of them from sticking all kinds of stuff into your USB ports. And they do occasionally foul things up.

[mrgasc]

Yes, I would try to contact the manufacturer, they should probably already know about the issue.

PS: there are many things to download from there, I would try to see if the problem also happens with their own software.

The problem does not happen with their software. It is restricted to my VB6 code. So, there is something in the code, which has worked fine for 15 years across WinXP and 7 and USB 1.1 and 2.0, that has stopped working for some Win10/11 machines.

The one Win10 machine that is working fine has USB 2.0 ports, rather than 3.0 or 3.1, so I'm thinking that that is playing a role. I still need to find the exact relationship between my code and the USB 3.0 ports that causes the problem though.

[Eduardo-]

The problem does not happen with their software. It is restricted to my VB6 code. So, there is something in the code, which has worked fine for 15 years across WinXP and 7 and USB 1.1 and 2.0, that has stopped working for some Win10/11 machines.

I think the problem is with their software.
The problem is with that DTAADC control. I guess it is a control and provided by them, since you never explained what DTAADC is.

If I am correct, then that DTAADC control comes from a DLL file that they provide.

The one Win10 machine that is working fine has USB 2.0 ports, rather than 3.0 or 3.1, so I'm thinking that that is playing a role. I still need to find the exact relationship between my code and the USB 3.0 ports that causes the problem though.

That can be, but they should specify what ports are supported and what aren't.

I don't think it is a problem of your program.

Of course, I'm not sure because I can't know for sure what DTAADC is and where it comes from.

[yereverluvinuncleber]

An obvious task would be to ensure that you install onto a machine that has just the o/s installed and no other software that could cause a conflict.

If you can build another PC that has the same spec. exactly as the desktop system that works well, then use that as your test environment. It should work. Then I would suggest you bring it up to the same spec. as the failing machines, item by item to see exactly which item fails. That should be possible.

When you have a working baseline then you have exactly what you need and it ought then to be a straightforward series of steps to find the error.

[dee-u]

What is the interval of your timer? Perhaps you could try disabling it before the procedure call then enable it again after the procedure call is completed. Just a stab.

[webbiz]

One other thought would be to try setting up a Virtual Machine on one of the problem Windows 10/11 computers and install Windows 7 or XP, then see if you can run the program in the VM without crashing.

This was going to be my suggestion as well. My clients are also using a very mature application I wrote when VB6 first came out. It had been working just fine and even works on many Windows 10 computers as well. Yet one client could not get it to work and while over TeamViewer I could not get it working either.

My suggestion was to try running it in a VM. That worked great that the user was happy to just stick with that.

While I'd like to know also what's the issue, testing on a VM might help narrow down the issue.

[-Corso->]

Although I'm not well versed in VB errors, I second dee-u's post above.
I had to stop and restart the timer execution on a Windows 10 machine as it would continually mess things up half way through other subs if left continuous.
So, in the timer function, I'd stop the timer, then at the end of the function restart it. Program ran perfectly then.

[TysonLPrice]

Maybe a firewall issue?

[vbwins]

You cannot crash a machine in user mode where VB applications run. Its just not possible. You have to be in kernel mode where the driver probably runs. Or you have to call some code that elevates to Kernel mode.

What is the bugcheck code?
Are all boxes at the same patch level?
Have you disabled antivirus? AV often has bits running in kernel mode

[yereverluvinuncleber]

I would discount all environmental issues first, anti/virus programs et al. Just start with a stable machine and install the o/s and nothing else. That should be the baseline for testing. Don't test on a fully configured system with all the corporate junk. Discount all that and you have a good chance of identifying the problem.

[Eduardo-]

The one Win10 machine that is working fine has USB 2.0 ports, rather than 3.0 or 3.1

That's most probably the cause (and the driver not handling that well).

[vbwins]

That's most probably the cause (and the driver not handling that well).

A bugcheck code and description would be useful.

[yereverluvinuncleber]

Stick a USB 3.0 card in the test box?

In the past I have had problems with on-board devices and their drivers. Installing a dedicated card from a known manufacturer who provides support and drivers with their devices is often the best way.

The on-board devices can be cut-down versions of a more premium product.

[mrgasc]

I greatly appreciate everyone's insights and comments. I inserted a powered USB-2.0 hub into the system and plugged the daq board into that. Thus far, that appears to have eliminated the problem. (The system has been running for 3 hours when it would typically crash in 2-20 minutes). I'm going to continue to let it run over the weekend. This does not address the software component and the underlying problem, but it may be a stop-gap to get my client's system back on its feet in the short-term. Next week, I will continue to delve into the software aspects, and I will try a few of the suggestions, such as potentially disabling the timer when not needed. The virtual machine also sounds interesting, but that would still be a band-aid, similar to my current usb 2.0 kluge. I’m hoping that I’ll be able to track it down at the base software level eventually.

I did pull up the windows error log and I checked it at all of the timestamps where I got a BSOD (I’ve logged over 30 crashes so far). There is no smoking gun there, no windows call or error that always proceeds a crash. In fact, in several cases, there was a 5-10 minute stretch of no activity being logged at all immediately proceeding the crash.

I'm an engineer who only moonlights as a “programmer”. I was tasked with maintaining and completing bug fixes in this existing VB6 code and I have managed to do that for quite a few years, but I'm not a sys admin or even a developer (I don’t know what a bug check code is, for example, or what it means for something to be running in kernel mode). This problem has been outside of my normal operating envelope, so I appreciate the help and the suggestions from everyone.

[yereverluvinuncleber]

A bit more testing and you should narrow it down. Try a few better quality USB 2.0/3.0 PCIe cards and you may get it working or at least it may hone in on the issue.

Putting it simply, kernel mode is the section of the o/s where high priority actions take place that can crash the whole system if they go awry. In a modern o/s, your programs 'should' be unable to crash the system as they ought to run in a less dangerous 'user' mode. That's the idea anyway.

[vbwins]

1) Bugcheck code. You should find it in the system section of the event log where it will be written either at the time of the crash or on restart

2) Memory is protected in windows where the CPU has to be placed into a particular mode in order to access memory. Operating system structures that can endanger the entire system are protected by having a bit set for the page that indicates that it is to be accessed by the operating system when in kernel mode. BSOD is actually a choice made in the code of the operating system itself when something is detected that should never have happened. Windows then halts operation and tries to log the situation in order to preserve integrity of user applications and data. Drivers run in kernel mode I think always.

good luck.

Edit

https://docs.microsoft.com/en-us/win...ode-reference2

Edit Edit

Windows should write either a full memory dump or a partial dump on BSOD

You should be able to correlate the time of a dump with a crash and send it to the driver vendor for their analysis.

The easiest way to locate the dump (its configurable usually %SystemRoot%\memory.dmp) is to go to the top level

c:\ dir /s *.dmp

c:\ dir /s *.mdmp