Can a Executable built with App Builder go corrupt and still launch ??

[MogaRaghu]

I have this client who has a 3 year old machine and which has a code built in LV2009. All was fine and then due to lack of jobs the machine was lying idle for about a year.

Now when he tries to run the same code ( that was running fine earlier ) on the same PC , he has a Auto sequence issue but almost rest of the screens work fine.

He now wants to check the code. No problem there as it is my code but it involves commercials which is not going to be easy. 

I am taking a stand to check the hardware / sensor calibration etc instead of even doubting the code . All i am telling him is

> The once a EXE is built it has a checksum included and everytime it is launched, it self checks for this and proceeds only if its OK.

> It is not possible for the code to get corrupted "somehow" at one point and still manage to launch and run for most part.

So i would like to know what is the real situation here ? Is my stand correct ?

[mikeporter]

I would be real dubious about your first point.

Yes, you can definitely have an executable get corrupted such that it sort of runs. An easy solution is to rebuild the application.

Mike...

[mikeporter]

Oh yes, you are right to the extent that if the logic worked a year ago and nothing has changed, it should still work. Case structures don't wear out or get rusty.

The issue is that there are a lot of other things that can do wrong: a corrupted hard drive, field wiring got stepped on resulting in unexpected errors, a different operator using the tool in a subtly different way stumbling across a latent bug -- lots of stuff...

Mike...

[MogaRaghu]

Thanks Mikeporter.

But my concren is this : When LV launches a EXE does it go thorugh any self diagnosis to check the integrity of the EXE ?. One common thing in the embedded world is to verify the checksum of the EXE that was generated during the build process. The EXE is launched only if the checksum tallies - else it aborts the process. How about LV in this area ?

[mikeporter]

I don't believe that the LabVIEW runtime does that.

Mike...

[MogaRaghu]

Very surprising, if so.

Looks like i have to take back my words and try and build a new EXE for the client ... (sigh)??

[Sam_Sharp]

It's a good idea to keep a zipped backup of the executable/installer that you sent to the client in the first place. It's also a reason why quite a lot of file download sites include an md5 checksum of the download so you can verify the contents were downloaded correctly. It might work if you signed the executable with a certificate as that might do some checksumming etc. for you to verify the file.

Bit rot is definitely a possibility.

[MogaRaghu]

Hmmm.. so it now looks quite probable that the EXE is partially corrupt. Fortunately I have the original source code so building the EXE is no issues.

This is a big learning . Thanks to all who posted.

I am as of now not closing this thread - let me load the newly built EXE and come back with the results.

[Hooovahh]

---

@MogaRaghu wrote:

Hmmm.. so it now looks quite probable that the EXE is partially corrupt.

---

Sure it's possible.  But of the 10-20 times a customer has came to me with a similar story, the solution was that something was changed, but they thought it was insignificant enough, not to tell me.  Oh yeah IT put on some anti-virus program but that doesn't affect your program.  Oh we put in a new network card why should that matter?  The computer died so we put the hard drive in a new one, but it doesn't work right.  Our UUT has a new software build but the software team says everything should work like it did before (but it doesn't).  Yeah we plugged in this USB DVD drive, and now the PC won't boot right.

Or there are times when they didn't realize what they were doing, not because of ignorance just slipped their mind or a new technician did something slightly different than they were supposed to.  We couldn't find the shortcut so we ran the first "My Program.exe" we could find, turns out it was several versions old.  The program was copied from a duplicate stand and the config was left behind.  The DAQ card was replaced and MAX wasn't configured right, or the software didn't detect it correctly for some reason.

Then there were times when people thought they knew what they were doing, but didn't.  Like being frustrated by failing parts, so they changed how the test was performed so that they would pass.  Only to find out months later that they were also now passing bad parts.  That one was interested because I think they tried to come after us for damages.

Maybe once or twice was the issue related to not changing anything significant and having software issues.  In one case the hard drive was dying and would take Windows 10 minutes to boot.  Then when you ran our program it didn't work right.  Of course in this case nothing really worked right.  In another case the computer fans were so clogged with dust and dirt that the CPU was over heating, and it would underclock itself to make less heat.  This again caused all software on the PC to be an issue, not just our EXE.

When these issues come up I try to have an open mind, and not claim I know the issue, only suspicions, or come up with reasons that it might be the way it is while trying to be as unbiased as possible.  No one wants to hear "This was your fault" only to find out it wasn't, and never to get an apology (this happens too often already).  That being said, most of the time a full development environment, with other hardware tools, and physical access to the machine is usually needed.  This can take time, and be costly.  On a few occasions I think management threatened to charge them large amounts of money if trips, and time were needed debugging issues that they should have been aware of.

[mikeporter]

To echo Brian, if I had a penny for every time l had to debug systems where "...nothing has changed..." -- I'd be a rich man. Though, to give the customer a bit of a break, it is not uncommon for IT departments to install things without user's knowledge.

Mike...