0

I have a program that spawns a notepad.exe file to display some text contents. The spawning code has been working fine for years on Win10 and for 9 months on Win11. It still works, sometimes, on Win11 ever since the recent Notepad app upgrade became available in the MS app store.

When my spawn code would start a notepad process, notepad would appear with a small notification ribbon that said, "A new version of Notepad is available. LAUNCH (that was a launch button). After a dozen times of seeing the prompt, I stupidly pressed the LAUNCH button and it did something behind the scenes and restarted with what i presume was the new app.

TROUBLES STARTED HERE

But the LAUNCH button kept showing up, so I figured I would update the app. I upgraded notepad from the app store. Then the problems started. The spawning operation kept failing with the error message shown below.

System.ComponentModel.Win32Exception HResult=0x80004005 Message=An error occurred trying to start process '"C:\Windows\System32\notepad.exe"' with working directory 'C:\Users\kkkwj\Documents'. The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail. Source=System.Diagnostics.Process StackTrace: at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo) at System.Diagnostics.Process.Start() at System.Diagnostics.Process.Start(ProcessStartInfo startInfo)

DEBUGGING ATTEMPTS

I also made SURE that I had reinstalled the latest C++ redistributables (x86 and x64) for and rebooted (again). But nothing helped. It still complains with the side-by-side error.

I checked the application event log, but that was empty because the notepad process probably never got started.

I ran the sxstrace tool, captured a binary log file, and converted it to a txt file. The txt file was 1KB and empty.

C++ redistributables installed and reinstalled, x86 and x64 versions

2010 10.0.40219
2012 11.0.61030
2013 12.0.30501 (x86 only - it is required by some system programs)
2013 12.0.40649
2013 12.0.40664 <-- I'm guessing this is the fixed KB3138367 version (see below)
2015-2022 14.32.33332

KB3138367: There was an issue with one of the MS 2013 releases where installing the x86 version would delete the x64 version.

They fixed it in KB3138367 and provided a new installer that would ensure both x86 and x64 versions were installed. I installed that one, reinstalled the latest notepad app from the MS store, and the issue seemed to go away for a couple of hours. Now it randomly appears - sometimes the spawn works, and sometimes it does not, even using the same code and initial commands.

VS2022 UNIT TESTS WORK FINE

In Visual Studio, unit tests of the spawning code seem to generally run fine (they failed when the vc_redist_xx were messed up, but seem to run fine now under VS 2022). But then, the VS2022 unit test runner creates its own special environment, I'm sure.

I have spent HOURS and HOURS trying to debug this side-by-side issue, but have come up empty-handed. Does anyone have other suggestions for what might be going on, or what I might do to fix it? Maybe I really do have a corrupted side-by-side configuration issue for notepad? And why do the VS2022 unit tests work fine if the s-by-s issue exists at the OS level? Thank you.

THE CODE

I build the code for NET 6, AnyCPU, net6.0-windows7.0, and publish it for win-x64 runtime.

 public static Process
    ProcesStartWithArguments(string exepath, string arguments) {

    var pinfo = new ProcessStartInfo();
 if (exepath.Length > 0 && exepath[0] != '"')
    pinfo.FileName = exepath.Quoted();
 if (arguments.Length > 0 && arguments[0] != '"')
    pinfo.Arguments = arguments.Quoted();

    pinfo.CreateNoWindow = true; // this is the dos window; normally we don't want it
    pinfo.WindowStyle = ProcessWindowStyle.Normal;
    pinfo.WorkingDirectory = FolderUtils.FolderDocumentsGet();
    return Process.Start(pinfo);
  }
Kevin
  • 1,548
  • 2
  • 19
  • 34
  • 1
    There seems to be a distinct lack of relevant code in your question. – John Aug 18 '22 at 04:37
  • 1
    What framework are you targeting? – John Aug 18 '22 at 04:38
  • Sorry, I updated the question with net6.0-windows7.0, win-x64 runtime, and the spawning code itself. Since you asked for the framework, now I wonder if side-by-side issues are different for NET core. – Kevin Aug 18 '22 at 04:56
  • 1
    Have you always been targeting .NET Core/6 or did this used to be a .NET Framework app? I ask because the error message mentions the working directory and the `ProcessStartInfo.WorkingDirectory` property value is interpreted differently based on the value of the `UseShellExecute` property. You're not setting `UseShellExecute` and the default value is different under .NET Core (`false`) than it is under .NET Framework (`true`). – John Aug 18 '22 at 05:05
  • Also, that code is rather strange. According to that, your method has two parameters but you never use either of them. Is that really your actual code? – John Aug 18 '22 at 05:06
  • Oops! You are correct on BOTH counts. I apologize profusely - I chopped out some documentation and what I thought was irrelevant path/args quoting code, but in doing so hid the assignments into the pinfo structure. I apologize again. On the second NET Core/Framework thought - you are exactly right again. It was NET Framework code 9 months ago. (But it has been working for months on NET Core). I had my ```UseShellExecute=true``` setting commented out because it was only required to use ProcessWindowStyle.Hidden (on NET). Should I set it to false on NET Core? – Kevin Aug 18 '22 at 23:29
  • I set the code to use ```UseShellExecute=true``` on the NET 6 code shown above. And the good news is that the supposed "side-by-side configuration is incorrect" has not appeared for 10 minutes. I have tried various code paths to reach the process start code, and all of them seem to be working fine - unit tests and in-real-life operations. Wow. I never would have found a subtle difference like the default value of UseShellExecute in weeks of searching! How in the world did you know that? THANK YOU. THANK YOU. (Crossing my fingers in the hopes that the problem does not resurface!) – Kevin Aug 18 '22 at 23:53
  • 1
    The change of `UseShellExecute` is breaking, and leads to a variety of issues (not only yours). Thus, it is rather well known since a few years ago. – Lex Li Aug 19 '22 at 00:42
  • 1
    Yeah, quite a few people have had issues related to the change in default value of `UseShellExecute` so that is pretty much always the first thing I check when an issue with `Process.Start` comes up. I imagine that it's been written somewhere but I'm not aware of why they chose to make that change. – John Aug 19 '22 at 00:59
  • Is there a public list of "breaking" code API changes somewhere that MS produces? I would look at it if such a list existed. – Kevin Aug 19 '22 at 05:52

0 Answers0