Been there, thought that.
After 5 years of me bashing my head against the brick wall of multiple customers different systems and different Windows updates and security releases, my boss at the time (the sparkie) finally knocked me up the said device in a quiet afternoon before Christmas then designed the PCB properly and charged it to a customer project and got 10 manufactured a few months later.
Saved me loads of hassle.
We'd sell them as required as part of a customer project - you can buy them of the shelf for about £60, but most competent sparkies like to do that sort of thing as a basic 3 hour design project at home. 😉
stop ripping you jeans by riding a barbed wire fence, it only gets more painful. 😂
(you have full control of the USB port from your app with this solution - and you get to implement a simple micro controller cmd on a PIC if you do it yourself)
We are constantly running into issues with our many many LabVIEW systems that range from the newest HW to some 24+ year old systems, every time IT performs OS or security updates. The DevCon code is attractive because it is re-usable & has worked great so far (until it didn't)!
You make this sound like it is mainly a LabVIEW problem. I would think that it is in fact not so much a LabVIEW problem unless you consider the fact that you can still nowadays run a LabVIEW application that was developed +24 years ago as a problem. 😀
LabVIEW allows you to pretty much integrate any number of anything in a number of ways into one single application. That is great but as soon as one of those many things decides to throw up its arms in despair because of an OS or driver update or simply a hardware defect too, this LabVIEW program fails in your eyes, yet LabVIEW is quite often in no way responsible for this nor could it do anything about it to prevent it.
And not seldom the main reason for such things can also lie in the fact that in the past when the application was designed, there were decisions made to go a certain path or choose a certain hardware, because it was easier, quicker, and/or cheaper to do so and this application was anyhow only going to be used for this quick test and then thrown away. 24 years later this same application is still used!
I don't think I am making it clear that I do not think any of this is LabVIEW's fault. I understand, and agree with what you and the other responders are saying. I have run into issues before that were caused by OS updates etc.. and we were able to figure those out and get the applications running happily again. I was hoping here to maybe find someone else that's had a similar issue recently and could point me towards what in the OS update has caused it, or what they did to fix it. I am well aware finding someone with the exact same problem reading this very thread is a longshot, but in the vein of "there are no stupid questions" thought I'd ask.
I am trying to keep these applications running as they are first, and if at some point where no more time can be spent figuring it out, we'll look into one of the hardware solutions folks were kind enough to offer.
Thanks very much for the replies, and happy holidays to you and yours!