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.


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.

  • 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 at 6:37

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:


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.

  • 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 at 6:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.