Exectuable OS.Version Sometimes Incorrect

[beavercreek]

Has anybody else had the data returned by OS.Version be unexpected?  One feature of my built exe started to fail, and digging in there is a section of code that changes based on operating system, therefore I was relying on a propety node (Application class Operating System:Version Number (OS.Version - short name)).

I did not have a problem before, and I don't have a problem with new applications I build, but with this large VI this has gotten incorrect.

Its suddenly returning 12.4 instead of the expected 6.1

I searched my entire registry for instances of 12.4 and found none.  The data returned by "ver" at a command prompt is as expected "Microsoft Windows [Version 6.1.7601]"

Left- existing executable (LV2012), middle LV2015, right LV2012

 

[Hooovahh]

Nope never seen that before, this does look like an odd one for sure.  My first suggestion is that this function might have an error going into it and that might cause it to return unexpected information.  But the output is a string, and if an error is put in, the output is an empty string.  Not sure how that could turn into 12.4.

Is it possible to post some code?  Maybe a minimalist case that reproduces the issue?  Is it even reproducible?  The work around is probably quite easy, to add code to accept this odd output and treat it like the 6.1 but why it is happening in the first place is an interesting one.

[beavercreek]

This morning I tried opening the main VI and doing a Ctrl-Shift-R before the build.  No change.

Then I decided to output all the OS Parameters.  They were ALL different from those reported in the development environment.

we had the thought to recompile the application in 2015 and see how that goes.  Same result.

I then took the two simple executables (LV2012 and LV2015) that I built yesterday, moved them to the standard install folder of the app, they still worked perfectly.

Then I renamed one of them to the name of my executable and that was the ticket.  If the simple apps have the same name as my troubled application, they report the strange data as above.  I moved them to a different machine and tried the same trick, no dice. so somehow, my laptop has been told to give this particular exe strange information.

I think my next move will be to uninstall and reinstall the application and hope that clears out the cobwebs.

[rolfk]

Would you care to tell us the name of your application that seems to make this problem? Windows maintains an internal compatibility database where various OS functions such as the OS Version number retrieval will actually outrightly lie to an application based on known incompatibilities of different appliciations. For that Windows uses pointers like the executable name and other characteristics of an executable to determine if it should start to lie about things.

Adding a prefix or postfix to your executable name would most likely be the easiest fix to this.

[beavercreek]

Yes, no problem, I've been sheepish about the name because its a little Orwellian ... TimeTracker.exe (tracks time toward projects, similar to Toggl, but with connections to our requirements and defect tracking tools, cost centers, etc.)

I'm now convinced I've brought this trouble on myself (of course :P)

A little history, my company has recently switched from well formed administrator UserID's to obfuscated non-administrator UserID's (don't get me started on how ineffective and inefficient obfuscated UserID's are).  So for new employees to the company, the application has several issues.  I started trying to find a list of Windows protected folders (where??), fixed an issue where it was reading a registry key*, and had not gotten to fixing the need to create and write registry keys...yet.   I got frustrated trying to find a checklist for creating normal-user apps and in trying to find all incompatibilities I started Microsoft's Application Verifier and wound up aborting that.  I'd be willing guess that was the start of my problems.

Has anyone seen/created a checklist or tool to interrogate a VI for normal (non-admin) user problems?

* for those with trouble reading a registry key on an non-admin account, Open Registry Key.vi -- had to change the Security Access Mask from KEY_READ|KEY _WRITE(the default) to KEY_QUERY_VALUE.

[JÞB]

---

@rolfk wrote:

Would you care to tell us the name of your application that seems to make this problem? Windows maintains an internal compatibility database where various OS functions such as the OS Version number retrieval will actually outrightly lie to an application based on known incompatibilities of different appliciations. For that Windows uses pointers like the executable name and other characteristics of an executable to determine if it should start to lie about things.

Adding a prefix or postfix to your executable name would most likely be the easiest fix to this.

---

Can you add a citation to that?  I could learn something today

Spoiler

I always do learn something every day but, this seams "Interesting."

[tst]

---

@JÞB wrote:

Can you add a citation to that?

---

The key term is "application compatibility". You can start here - https://msdn.microsoft.com/en-us/library/bb432182%28v=vs.85%29.aspx

Specifically:

File attributes are metadata associated with a file on disk. 
These attributes include the file name, file size, checksum, version, and date. 
These attributes are used to determine whether a file being loaded by the system 
matches a database entry

The basic idea is that Microsoft really wanted users to have a completely smooth upgrade experience and so they put together a team dedicated to finding issues with various programs and either getting the publisher to fix it or setting up various options so that the program will run even though it did something wrong. If you want, there's a Microsoft developer called Raymond Chen who has a blog which occasionally includes stories about specific issues. I'm sure there are other stories around too.

[beavercreek]

I have finally succeeded in stopping Windows from lying to my executable!  Specifically, I opened Application Verifier (which got me into the trouble), selected my executable in the list and turned off the Compatibility -> HighVersionLie.

In the mean time I had read more than I care to about sdbinst (and shimming), where sdb's are typically installed, etc. and struck out all over the place.

The other information I've gathered is that the "Standard User Analyzer" is the specific tool that I should run on my application.  After installing the Assessment and Deployment Kits I found the "SUA" here C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Application Compatibility Toolkit\Standard User Analyzer. (it was not in the start menu) 

Now my main problem is that I cannot figure out how to run the Standard User Analyzer as a standard user!  Well, I do have a workaround, a coworker logs in my machine, neuters me, and then I can start testing, but this is not the ideal method as I invariable find the need to switch myself back into admin rather quickly.

I tried creating a new standard user account on my machine, but something in my company's group policy doens't allow that user to log in.

I also (several times) have run into tips about set __COMPAT_LAYER=RUNASINVOKER.  This will prevent auto escalation for exe's that are detected to be installers and will override any included manifest, but since I'm an admin, it doesn't really help me either.

I'll keep updating this thread.

[Yamaeda]

If you run from the development environment you get the LV version instead. It might not be applicable in this case, but program.version acts that way.

/Y