Windows Installation issue - Internal Warnings

[sth]

Yeah, I know, it is weird for me to be complaining about a windows installation.  BUT maybe my background of having things "just work" makes me a bit picky.

I took a clean VM of Windows 10 and installed LV 21-64 bit and then LV 21-32 bit.  The 64 bit version seems to work just fine.  But the 32 bit version gives two warnings upon launching.  Not sure why.  I have attached screen shots of both warnings.

#1 Internal Warning 0x6A0F9DBF: objparser.cpp, line 1591

#2 Internal Warning 0X81434D8F: objparser.cpp, line 1602

Note: these are "internal" but objectively useless warnings with no information to the user.  That is just rude.

[Christina_R]

I've created Bug1508008 for this issue. Thank you for the feedback!

[robdye · Accepted solution]

These particular warnings indicate an error parsing .rc(h) files in the resource/objmgr directory, and are certainly unexpected.

Apologies for the rudeness of the dialogs, but during the beta program, these kinds of warnings are purposely made more aggressive (dialog shows at the moment they happen) to encourage our beta testers to report problems. In a release version of LV, this warning would show up at clean exit or next launch.

In either case, more information about the problem is written to the LabVIEW log file in the temp directory. On Windows, you can locate this file by typing "%temp%" into the path field at the top of an Explorer window. In that directory, look for a file name of this form:

<exename>_<bitness>_<vers>_<user>cur.txt

For instance, I have one in my temp folder named:

lvre_64_21.0b65_rob_cur.txt

The log file is overwritten with each new launch of LV, but the most recent one is renamed with the suffix "_log.txt" .

If you provide us with your log file, I expect it to contain information for these warnings that includes the filename and line number where the parsing error occurred.

Rob 

[sth]

(Hi Rob!)

Actually the "internal warnings" are always terse and cryptic.  In general, having a some sort of a pointer as to where the error is, makes for good feelings.  Whether beta or release...  It is a Windows tradition to be cryptic.

I will go look for the log files.  I know where they are on the Mac OS (in the LabVIEW Data folder in Documents).  But Windows has many hidden directories.  I was only beta testing in Windows because I had the XML parsing error from my FPGA code that was annoying.

[robdye]

I forgot to mention that it will be most helpful to provide us with both the log and the particular .rc(h) file that is mentioned in the log.

[sth]

Here is the log file that seems to have issues with several .rch files.  I do not know where these rch files are supposed to be, but it seems that these two files are a problem?  If the files are missing should LV just create a default or blank file?

Separator ':' missing. File nisysapiRef.rch, line 1.

illegal keyword in header file. File nisysapiRef.rch, line 1.

separator ':' missing. File nisyscfgRef.rch, line 1.

illegal keyword in header file. File nisyscfgRef.rch, line 1.

separator ':' missing. File nisyscfgTag.rch, line 1.

illegal keyword in header file. File nisyscfgTag.rch, line 1.

Is it just that maybe these files are missing?  I tried to re-install the 32 bit LV 21 but was told there is nothing to install.  I will try "repairing" the package?

[robdye]

These files are located in the <lvdir>/resource/objmgr.

On your Windows machine, <lvdir> for your 32-bit LV will be "c:\Program Files (x86)\National Instruments\LabVIEW 2021\".

In my 2020 installation. nisysapiRef.rch contains this text:

genericType: nisysapi
genericTypeName: "System Config"
RCversion: 4
control: nisysapi.ctl
objtype: Refnum
sorted: no
adapt: yes
matchExact: withInheritance
menuSelect: yes
library: nisyscfg.*
closeFunction: nisyscfg_lv_Close
termName: "System Hardware"
termNameOut: "System Hardware out"
cleanup: idle
calling: C

[sth]

Found the files.   My nisysapi.rch file has 328 bytes of nulls.  The nisyscfg.rch file has 398 nulls in it.  This was after repairing the LV 21 - 32 bit installation I have those two files as (excuse the linux diagnostics):

% l Documents/Winders\ Shared\ Folders/Winders\ LV\ 21/*.rch
47782567 8 -rwxr-xr-x  1 sth  admin  328 Apr 10 17:28 Documents/Winders Shared Folders/Winders LV 21/nisysapiRef.rch*
47783034 8 -rwxr-xr-x  1 sth  admin  398 Apr 10 17:28 Documents/Winders Shared Folders/Winders LV 21/nisyscfgRef.rch*
% od -a Documents/Winders\ Shared\ Folders/Winders\ LV\ 21/nisysapiRef.rch 
0000000  nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0000500  nul nul nul nul nul nul nul nul                                
0000510
% od -a  Documents/Winders\ Shared\ Folders/Winders\ LV\ 21/nisyscfgRef.rch 
0000000  nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0000600  nul nul nul nul nul nul nul nul nul nul nul nul nul nul        
0000616
% 

I can post the files if you want, but they are really much ado about nothing....

[sth]

also the file "nisyscfgTag.rch" is full of nulls as well.  I just did a dump of all the files.  The other 16 files seem to have text in them.

-Scott

[robdye]

I'm guessing that this problem is machine specific. Fresh in-house installs of the latest bits (considerably later than you are working with) show that these files have the expected contents.

If this were a problem with the installer, then I would expect every beta customer to be complaining about a warning dialog at launch. We are unaware of any other reports of this behavior.

You said in one of your posts that you tried to "repair" the install. What exactly did you do and what were the results?

If results were the same, would you be willing to uninstall and try again to see if this is reproducible?

Could this be a file system problem on your machine? Can you run a file system check? (I've never done this, but google will tell you how.)