Win32Exception Issues

kwhelchel

Well-known member
Joined
Feb 28, 2020
Messages
53
Programming Experience
Beginner
Console application that is made to execute the USOClient.exe with the switch of "StartDownload". Error states as follows "System.ComponentModel.Win32Exception: 'The system cannot find the file specified' "

C#:
  static void Main(string[] args)
        {
            System.Diagnostics.Process pProcess = new System.Diagnostics.Process();
            pProcess.StartInfo.FileName = @"c:\Windows\Sysnative\UsoClient.exe StartDownload";
            pProcess.StartInfo.Arguments = inputPath + " " + outputPath;
            pProcess.Start();
            pProcess.WaitForExit();
            pProcess.Close();


        }

Any suggestions would be great.
Thanks
 
"StartDownload" is one of the arguments, not filename.
 
My understanding is that UsoClient.exe lives in the System32 directory, not the SysNative directory. That maybe another reason why you are getting an error about the file not being found once you fix the first issue pointed out above.

Out of curiosity, why would are you trying to force the running of UsoClient.exe?
 
Does anybody else also find it mighty annoying that Windows always says "the file specified" instead of telling you the name of the file it has failed to open ? Would that be guided by some design principle or security concern ? In some cases you have no clue at all what file some process is trying to open, and you have to run Process Monitor to find out.
 
Because the way the underlying Win32 API is designed, it is obvious what the specified file is. In the case of ShellExecuteEx(), there is only one filename parameter. And it's a matter of the old school GIGO programming principles. They also used to assume that you would RTFM before using any particular API. It's only later that programming API designs changed over to "try it to find out what happens". It's in that change when you want to try to handhold the caller and tell them exactly what they did wrong, just like Steve Jobs telling you that you are holding your iPhone 4 wrong.
 
Because the way the underlying Win32 API is designed, it is obvious what the specified file is. In the case of ShellExecuteEx(), there is only one filename parameter. And it's a matter of the old school GIGO programming principles. They also used to assume that you would RTFM before using any particular API. It's only later that programming API designs changed over to "try it to find out what happens". It's in that change when you want to try to handhold the caller and tell them exactly what they did wrong, just like Steve Jobs telling you that you are holding your iPhone 4 wrong.
Yes, yes, I well know that in this particular case it is perfectly obvious which file it is ! My observation was a general one. I've had many occasions where Windows really left me clueless as to what it was trying to do, making RTFM a non-option. I still don't understand why so many programmers can't be bothered to give a decent and informative error message, instead of assuming it should be obvious to everybody. Like "The operation failed!" or "The command was carried out successfully".
 
Check out Winerror.h. Unless your team within Microsoft is willing to take on the cost of adding a new error code AND enlisting a localization team to localize the error message in all the languages, have your testers verify the error message looks correct for all languages that Windows supports, as well as, have the Windows SDK team to pick up your new error codes, and localized strings for the next release of the SDK, you will likely choose to recycle any existing error codes.

Some of those error codes will have error strings that do include the filename or parameter value. Unfortunately, the file not found and path not found error codes actually pre-dates Windows NT. It is the same error codes from MSDOS which originally did not include the offending file name or path in the error string.
 
@Skydiver the reason why I am doing this is to force windows to download and install updates on a controlled schedule by us. Our software is windows base and needs the current updates to be done to keep windows happy. The windows forced updates by Microsoft either throttles the network connection and or just will force a reboot. This has a had a huge impact on clients during there operating hours and interrupting there business.

 
And if the built in Windows solutions are not enough, Microsoft also offers enterprise level support to control what updates gets pushed and when via WSUS and SCCM.
 
Back
Top Bottom