This happens occasionally with standalone builds for Mac, Linux, and Windows as well as for WebGL builds. The build in the video showing this occurring is a WebGL build. I have not tried making mobile builds in a while but this possibly happens there as well. Has anyone had this happen to them as well?
Reminds me of pseudo-viruses back in the DOS days. They would do things like drop random letters to the bottom in any DOS app, driving the user crazy.
The way it seems to pop up random (but already open?) windows to the foreground makes me think this has nothing to do with Unity. At best, making a build triggers this behaviour. Check what kind of tools and resident apps you have installed and kill them one by one and check if the issue goes away.
After building unity will once every 100 times or so, open every single application I have on my computer till I have to restart. Unity are aware of the problem but as far as I am aware there still to this day is no fix, and this has been at least 18 months now.
This seems related to that in some way as its similar behaviour, but my applications were not already open
Some of my windows/applications were open, but a solid majority were not just like your case, @MadeFromPolygons_1 Definitely interesting to know I’m not alone, though. Thanks for replying guys.
Off the top of my head it might be doing some creative use of “start” command or some sort of registry walking (on windows). Registry contains “open” action for every single filetype. It might be doable somehow through something akin to shell execute, because some applications introduce their own protocol on computer, like valve’s steam:// .
Frankly I stopped asking “How” around time when Microsoft broke Calculator during windows update. It wouldn’t launch. Prior to that time I’ve been naively thinking that a calculator is a type of application that is nearly impossible to break due to how simple it is supposed to be. Yet there it was.
I sporadically have the same issue of unity opening all windows (even hidden ones that are not designed to be visible, like internal nvidia driver windows) since at least Unity 2018 while exiting the debugger (either using continue after a breakpoint or detaching the debugger) but I could never pin down the cause and neither could jetbrains where I reported that bug to.
Funny saying that, Paint app is dead simple app too right?
I remember on win 10 had issues with putting PC to sleep reliably, because Paint was open. Only until I found out somewhere accidentally on the net, that someone had similar issues. After closing Paints instances, things start working.
However, more on topic, I had also issues on win 10, to change volumes, when Unity was entering play mode, or was hanging. It was blocking Win OS access to basics utilities, like audio controls.
It was just an interaction with a Unity developer from a forum thread, I had no idea how to create a reproduction case for this to upload so a bug was never filed
Just FYI while I have your ear - In general the whole “do you have a repro case to upload” wall really gets in the way of what would otherwise be a lot of bug reports reported. I understand why they are useful, but they shouldnt be necessary to look into the issue
If a reproduction case is not available you at least need to be able to provide the steps to reproduce. A description of a behavior is almost never enough by itself to fix bugs in software.
Right but in this case how exactly is that done? This isnt a regular bug, this is literally once in a blue moon it goes absolutely off the rails and opens every single application. I have no reproduction steps. It is seemingly random behaviour, the only “steps” are what I told the developer - it happens once in a while after a build. Thats it. Thats the steps. My point was, this would not be considered enough of a repro by the current reporting process despite it being the only available information and the issue being very real and persistent.
I understand how software bugs are fixed thanks and am well versed in the bug reporting process, but I also hope you understand that some bugs are unable to provide even the steps to reproduce. This doesnt mean they are not real software issues.
I agree with you. I wish this wasn’t the case, but the way things work right now, most teams have their hands full with various bug fixes, improvements and features so they will naturally take things out of their backlog instead of from the forum. You may get lucky once in a blue moon to get a developer who works in that exact area of the product to notice your issue and make an internal bug out of it but reading forums is not part of our jobs so most don’t bother.
To find the applications spawned by a specific application, you can use various system monitoring and analysis tools available for Windows. One commonly used tool is Process Explorer, which provides detailed information about running processes, including their parent-child relationships.
Here’s how you can use Process Explorer to determine the applications spawned by a specific application:
Launch Process Explorer: Run the downloaded executable (procexp.exe) to launch Process Explorer.
Find the Parent Process: In Process Explorer, use the search function (Ctrl+F) or manually locate the process that you are interested in. Once you find it, right-click on the process and select “Properties.”
View Child Processes: In the process properties dialog, navigate to the “Image” tab. Here you will find a hierarchical view of the selected process and its child processes. Child processes are listed under the parent process, indicating the applications spawned by it.
Process Explorer provides additional details about each process, such as process ID (PID), command line arguments, CPU usage, and more. This information can help you identify and analyze the applications spawned by the specific process.
Please note that Process Explorer is just one of many tools available for process monitoring and analysis on Windows. Depending on your specific requirements, there may be other tools or methods that are more suitable.