1

I ran the following script in my Windows 10 command prompt msinfo32 /report mysystem.txt, which saves all the system data of the machine in a single text file.

However, when I ran strings on the output text file, I wasn't getting any output. findstr /c:"System Name" mysystem.txt should display the system name, but it didn't return anything. I opened the file, and all the text was there, but findstr was not recognizing it.

Eventually, I changed the file extension to .csv, opened it in excel, and saved it as a 'Text(MS-DOS).txt' file. Don't ask why I thought to do this, I was just grasping at straws. I was then able to run strings on the file saved as a 'Text(MS-DOS).txt' file with success.

Can anyone explain this behavior? I thought a text file was a text file, as long as it's plain text. How can I get the command line to direct output in the Text(MS-DOS).txt format. I couldn't find options for this in findstr and google searched yield nothing.

Thanks in advance for any assistance.

efw
  • 111
  • 2

2 Answers2

0

That might be because the resulting mysystem.txt is encoded in UTF-16. On a Unix system the file utility can be used to show that:

$ file mysystem.txt 
mysystem.txt: Little-endian UTF-16 Unicode text, with very long lines, with CRLF, CR line terminators

So, to a plaintext utility like findstr the file mysystem.txt really looks like something like this:

$ cat -v mysystem.txt | head -1 | cut -c-80
M-^?M-~S^@y^@s^@t^@e^@m^@ ^@I^@n^@f^@o^@r^@m^@a^@t^@i^@o^@n^@ ^@r^@e^@p^@o^@r^@t

Other tools may be able to understand UTF-16:

$ head -1 mysystem.txt | cut -c-80
��System Information report written at: 0

I don't know why msinfo32 decides to write out UTF-16 files, maybe it wants to make sure that really all (system) information is captured for all Windows installations in various parts of the world (where UTF-8 is not enough) and I did not find a switch to force msinfo32 to use a different character set.

There may be a Windows command line tool to convert files into different character sets, but I don't know any. So here's a Linux snippet again to do just that:

$ iconv -f UTF16LE -t UTF8 mysystem.txt -o mysystem_8.txt

And the resulting mysystem_8.txt file can now be fed to findstr:

$ findstr /c:"System Name" mysystem_8.txt
System Name: WIN11
System Name     WIN11

In Windows one could open the file with notepad.exe, save the file again ("Save as") and in the Save file dialog choose another encoding (UTF-8, or ANSI). But I don't know a Windows command line tool that does the same. GnuWin32 does the trick, but one would have to install that first.

ckujau
  • 642
  • 4
  • 13
  • Thanks for the detailed response. I noticed when opening the output file in notepad++ it was encoded originally in UCS-2 LE BOM, which I guess is a unicode format. You can convert the file to UTF-8 by using TYPE before the original file followed by > newfile.txt. Newfile.txt will be readable by findstr. – efw Jan 24 '19 at 06:37
0

The reason you are running into this problem is because msinfo32 encodes the text file in UCS-2 Little Endian format and findstr does not support UCS-2 Encoding. When you open the text file in excel and resave the document, it encodes the file in UTF-8 which is supported by findstr. A workaround to this problem is the following:

msinfo32 /report mysystem.txt
type mysystem.txt > utf8.txt
findstr /c:"System Name" utf8.txt

The type command will display a text file on the screen but when using the > character, it will redirect that output to a text file which gets encoded in UTF-8.

If you are simply trying to get the machine name, you can run the following command:

hostname

A more elegant way to retrieve system information is via powershell which would allow you to retrieve everything you can with msinfo32 plus much, much more. Just do a google search for the inventory item you are looking for and powershell. For example, search for get hostname powershell.

Joe
  • 1,170
  • 1
  • 8
  • 12
  • I looked at powershell and I'm out of my depth with it for the time being. This is all still very new to me, and learning powershell appears to be a much steeper learning curve. Thanks for the helpful workaround, – efw Jan 24 '19 at 06:39