Draft version of a new .NET Framework setup verification tool available for download

A while ago, I published a .NET Framework setup verification tool that can be run to provide a sanity check of the install state of the .NET Framework 1.0, 1.1 and 2.0 on a system.  However, there are some limitations in that tool:

  • It does not support validating the .NET Framework 2.0 on Windows Vista

  • It does not support the .NET Framework 2.0 SP1, the .NET Framework 3.0, the .NET Framework 3.0 SP1 or the .NET Framework 3.5

  • It only checks file version information and does not check registry values created by setup

  • It depends on the setup technology used to install the product in the first place (Windows Installer or OS install technologies) and requires you to select an OS-specific version of the product in the UI in order to get accurate verification results

  • It reports misleading warnings if hotfixes for the .NET Framework are installed on the system

As a result, I decided to create a new verification tool, and I have an initial version that I think is ready for more people to use.  I wanted to post some information about the tool so that folks can try it out to verify the installation state of the various versions of the .NET Framework on their systems.

Where to download the new verification tool

I have a draft version of a new verification tool that can be used to verify all versions of the .NET Framework (1.0, 1.1, 2.0, 2.0 SP1, 3.0, 3.0 SP1 and 3.5) on any supported OS and processor architecture.  You can find information about the tool and download it from this location:


The UI for the tool is straightforward – it contains a drop-down list box that lets you choose the version of the .NET Framework that you would like to verify and a Verify Now button to initiate the verification process for the chosen product.  After verification completes, it will display results for the chosen product and allow you to select additional products to verify.

I have been testing this new version on several systems that I have access to, but there are likely to still be issues where the tool falsely reports errors or misses some error cases.  Please let me know if you see any issues while using this tool by posting comments on this blog post or by contacting me directly.  If possible, please include information about your scenario and copies of the log files that I describe below so I can continue to make this tool better in the future.

How to run the tool in silent mode

This verification tool supports running in silent mode if you would like to automate the verification process.  To run in silent mode, you need to download the verification tool .zip file, extract the file netfx_setupverifier.exe from the .zip file, and then run it using syntax like the following:

netfx_setupverifier.exe /q:a /c:”setupverifier.exe /p <name of product to verify>”

The value that you pass with the /p switch to replace <name of product to verify> in this example must exactly match one of the products listed in the file setupverifier.ini that is included in the self-extracting package for the verification tool.

Currently, the verification tool includes the following product names that can be passed in using the /p switch:

  • .NET Framework 1.0

  • .NET Framework 1.1

  • .NET Framework 2.0

  • .NET Framework 2.0 SP1

  • .NET Framework 2.0 SP2

  • .NET Framework 3.0

  • .NET Framework 3.0 SP1

  • .NET Framework 3.0 SP2

  • .NET Framework 3.5

  • .NET Framework 3.5 SP1

For example, if you would like to run the tool in silent mode and verify the install state of the .NET Framework 2.0, you would use a command line like the following:

netfx_setupverifier.exe /q:a /c:”setupverifier.exe /p .NET Framework 2.0″

The verification tool returns the following exit codes:

  • 0 – cleanup completed successfully for the specified product

  • 1 – the required file setupverifier.ini was not found in the same path as setupverifier.exe

  • 2 – a product name was passed in that cannot be verified because it does not support installing on the OS that the tool is running on

  • 3 – a product name was passed in that does not exist in setupverifier.ini

  • 100 – verification failed for the specified product

  • 1602 – verification was canceled


This verification tool creates 2 log files by default that can be used to determine what actions the tool is taking and what errors it encounters while verifying a product.  The 2 log files are listed below, and they are created in the %temp% directory by default.  Note that you can find the %temp% directory by clicking on the Windows start menu, choosing Run, typing %temp% and clicking OK to open the directory in Windows Explorer.

  • %temp%\setupverifier_main_*.txt – this log contains information about all actions taken during a verification tool session; it will include information about each resource that the tool attempts to verify for a chosen product and whether or not that resource was found on the system; this log tends to be fairly long, so errors will be logged with the prefix ****ERROR**** to make it easy to search and find them

  • %temp%\setupverifier_errors_*.txt – this log only contains information about any errors found during verification of a chosen product

A new pair of log files will be created each time the verification tool is launched.  The date and time the tool is launched will be appended to the end of the log file names by default in place of the * in the names listed above.  If you want to control the exact names used for the log files, you can use the following command line parameters:

  • /l <filename> – specifies a name to replace the default value of setupverifier_main_*.txt for the main activity log for the verification tool

  • /e <filename> – specifies a name to replace the default value of setupverifier_errors_*.txt for the error log for the verification tool

For example, the following command line will allow you to specify non-default names for both log files:

netfx_setupverifier.exe /q:a /c:”setupverifier.exe /l %temp%\my_main_log.txt /e %temp%\my_error_log.txt”

<update date=”9/2/2009″> Fixed broken link to the verification tool. </update>


Comments (27)

  1. JeroenV says:

    I’ve used this tool before to check if a certain version of .NET was installed on my system: http://www.asoft.be/prod_netver.html

    It is very easy for users to find out if they have a particular version, and if even provides links to the download site of the particular version if it’s needed to install.

    For the .NET developers they allow you to distribute it along with their tools.

    My 2cts

  2. Hi JeroenV – Thanks for sending the link to this utility.  I can’t tell how in-depth this tool goes in checking the install state of the .NET Framework though.

    I have run into cases in the past where the registry value that is officially documented as the way to detect the .NET Framework install state exists, yet something is wrong with the install and it doesn’t work correctly.  That is the type of scenario I was targeting when I created the verification tool described in this blog post.

  3. lrios80 says:

    Does this verification tool check the integrity of the .NET files (check to see if any files might be corrupted), or does it only check if the files are installed?

  4. Hi Lrios80 – Currently, the tool only checks for the existence of files in specified locations.  I am open to suggestions regarding checking for corruption.  The previous version of the tool contained some checksum information that it would compute and compare against, but that logic doesn’t work if any service packs or hotfixes are installed for the .NET Framework.  Do you know of any other ways to check for file corruption from a tool like this?

    Also, have you run into cases where files have gotten corrupted for the .NET Framework?  If so, do you have any more information about how that happened and how you figured out the root cause?

  5. lrios80 says:

    I’ve run into some cases where programs would not load, so .NET had to be uninstalled then reinstalled or repaired before it would work. The only time I’ve been able to find a specific cause for it was when SP1 for .NET 2.0 was downloaded and installed and the installation failed. (I’m not sure if this would be file corruption or if some files were removed when SP1 tried to install and then were not restored when the installation failed.) .NET 2.0 had to be completely uninstalled then reinstalled.

  6. Hi Lrios80 – Thanks for providing more details about this scenario.  I’ll keep an eye out and see if I run into any similar .NET Framework 2.0 SP1 failures and check out the exact state of the files that are a part of the .NET Framework in that case.  If you run into this again, can you also try out the new verification tool and see if it reports any errors that might help narrow this down further?

    It would also help if you could send me any log files you have from one of these failures – the .NET Framework 2.0 SP1 creates a verbose log named %temp%dd_net_framework*.txt during installation.  You can send the log to Aaron.Stebner (at) microsoft (dot) com.

  7. Details about the .NET Framework 2.0 setup packaging Available command line switches for .NET Framework

  8. szilvaa says:

    Regarding how you could check the integrity of the files: could you verify the digital signature? I suppose hotfixes keep that up to date.

  9. Hi Szilvaa – Yes, I think that would help for files that are digitally signed.  I’m not sure it fully guarantees that the files are not corrupt, but it would be a step in the right direction.  The trick there is that not all files in the .NET Framework are digitally signed, so the tool would need to keep track of which ones are and which ones aren’t.  I’ll look into options for doing something like this in the future.

  10. elguido says:

    Hi Aaron

    Is there a nice way to use your tool to scan dotnet installs across a LAN (assuming authentication requirement has been met)?

    Currently the best we have is the prospect of rclienting and running against network share and collating on network share.

    Your thoughts would be most welcome.



  11. Hi Elguido – This verification tool is designed to run on the local computer and return results from that computer.  It doesn’t support running remotely across a network.  What I’d suggest doing here is scheduling some kind of job/task to run the tool on the machines on your network, and then collect the logs it creates and upload them to a network share for centralized analysis.  Hopefully this will be feasible in your scenario.

  12. elguido says:

    That could work for us, thanks Aaron.

    The only reason I asked is your method involves loads of signoffs and the like, the approach I’m heading from is something that the frontline support staff (of which I am a member) can organize on their own users.

    If there is any scope to handle UNCs that’d be excellent?



  13. こんにちは! フォーラム オペレーターの服部 清次です 昨日、郵便局に荷物を取りに行ったら、年賀状の案内ポスターが貼ってありました。 約 60 年の歴史を持つお年玉付き年賀はがきも、最近では時代の波を反映して、当選商品にデジカメなどが用意されていますが、今年は一体どんな商品が当たるのでしょうか?

  14. jschlager says:

    Hi Aaron,

    I’m trying to use the draft version of your tool in silent mode on my local machine. The interactive version is working fine, but I had no success using the /p switch so far. I’ve used the syntax from the included readme.txt and after a call to

    ./netfx_setupverifier.exe /q:a /c:"setupverifier.exe /p .NET Framework 1.1"

    the program quits without any noticeable action and without setting the exit code. Even if I extract the files from the archive and call

    ./setupverifier /e "d:error.txt" /l "d:log.txt" /p ".NET Framework 1.1"

    nothing happens. I’ve tried both with and without quotes, using cmd32 and the windows power shell and would appreciate any hints…



  15. Hi Jschlager – There is information about how to run the verification tool in silent mode in the user’s guide at http://blogs.msdn.com/astebner/pages/8999004.aspx.  I have tried the following command line and it works fine:

    netfx_setupverifier.exe /q:a /c:"setupverifier.exe /p .NET Framework 1.1"

    You need to make sure the EXE is in the exact path that you’re using for your command line.  Also, in silent mode, the program doesn’t display any progress UI during verification, so you need to look at the log files it produces to determine exactly what it is doing.

    I’m not sure what the ./ syntax is that you listed before the names of the EXEs that you’re running, but that could be the problem here.  It gives me an error if I try to do that on my system, but that isn’t being caused by the verification tool – I can’t run any command with syntax like that.

  16. jschlager says:


    the syntax I’ve posted is for calling the executable from the windows power shell. I’ve tried with cmd32 and without the "./" part, but had no success.

    The setupverifier does not do anything on my system when started in silent mode. There is no logfile or errorfile, the executable just returns immediately without setting the exit code.

    BTW, I’m using a modified MUI version of Windows XP SP2, currently with the German language packs.

    Again, the interactive version is working fine.

  17. Hi Jschlager – I’m not sure what to suggest here.  The command line syntax documented in the users guide consistently works for me on all systems that I’ve ever tried the tool on.  Can you post a screenshot that shows the exact command line you’re using and the exact way that you’re launching it (is it a cmd prompt, or a batch file or something else for example?)

  18. jamieleecho says:

    Thank you for all of our insights into .NET.

    I gave this a try on my Windows XP SP2 laptop and the UI works well.

    Unfortunately, when I use the command line mode and enter bogus things like:

    netfx_setupverifier.exe /q:a /c:"setupverifier.exe /p .NET Framework 10.1"

    netfx_setupverifier always returns 0. The internal setupverifier seems to be doing the right thing according to the log, but it seems that the netfx_setupverifier is hardcoded to always return 0.

    I extracted the setupverifier program and ran it separately and it indeed is returning the expected error – so something seems to be getting lost between the two. In this case, my command line would look like:

    setupverifier.exe /p .NET Framework 10.1

    Am I doing anything wrong here?

  19. Hi Jamieleecho – The .NET Framework setup verification tool is a Windows application, not a console application.  This means that it returns the appropriate error code to the calling process in this type of scenario, but it does not update the %errorlevel% environment veriable that it sounds like you’re checking in your scenario.  You’ll need to have your calling process check the return code and/or manually set the errorlevel to the return code of the verification tool if you need it to work the way you’re describing.

  20. SPACESHIP says:

    Hi, I used your program to check if .net framework was correctly installed on a win98 machine – it reported me several missing dll files and following errors:

    Error: GetProcAdress failed for SHGetFolderPath with error code 127

    Error: Unable to ind an ExecutablePath value for custom action ‘Custom Action – .NET framework 2.0 test application’, exiting now

    I guess these two are connected somehow, but I dont know how to fix it. There is already the shfolder.dll in windowssystem what else do I need to do?

  21. Hi Spaceship – To fix the missing files, I’d suggest uninstalling and re-installing the version(s) of the .NET Framework that you have installed on your system.  The steps at http://blogs.msdn.com/astebner/archive/2008/03/07/8108332.aspx might be helpful too if you run into any uninstall issues.

    For those 2 errors in the verification tool, could you please upload your verification tool log files to a file server (such as http://skydrive.live.com) and then reply back with a link to the server location so I can take a look and see if I can figure out why the tool is reporting those errors on your system?

  22. Vinay says:

    Hi Aaron,

      can we use this tool to determine whether .Net 3.5 Language Pack SP1 (for different languages) is installed?

    If not, do you know any tool or utility or documentation that help us to determine this?

    Thanks in advance.


  23. Hi Vinay – No, the verification tool does not support verifying the .NET Framework language packs.  I haven't run into enough installation problems with the language packs to justify the work needed to update the tool to support the language packs.  Are you seeing specific problems that you're trying to diagnose?  If so, I could look into adding some verification logic to the tool for you or something like that.  I'd like to understand more about the issues you're seeing first though if possible.

  24. Leon says:

    Ich hoffe du kannst es übersetzen ^^

    Ich versuch schon länger das programm zu installieren, aber jedes mal stürzt es ohne Grund ab.

    Und ich habe nichts gefunden was helfen könnte…

    Bitte um Rückmeldung


  25. Hi Leon – Are you seeing this crash when you try to install the .NET Framework, or when you try to run the verification tool?  If it is when running the verification tool, please download the new version that I posted today – I have made a couple of fixes that should solve these issues.

    If you try with the latest version of the tool from today and it still crashes, please let me know which exact version of the .NET Framework you are trying to verify, which version of Windows you have on your computer, and if possible, please upload your verification tool log file to a file server (such as http://skydrive.live.com) and reply back here and provide a link that I can use to download your log file and take a closer look.