Search Issue Tracker
Fixed in 2019.3.X
Votes
0
Found in
2017.4.0f1
2018.4.0f1
2018.4.2f1
2019.2.0a1
2019.3.0a1
2020.1.0a1
Issue ID
1180571
Regression
No
Command line argument -adapter not working when running two instances at the same time
How to reproduce:
1. Make sure that you have two or more connected monitors
2. Extract "CmdLineAdapterMultipleInstances.zip"
3. In "CmdLineAdapterMultipleInstances" folder navigate to "Buildas" folder
4. Run "withoutTimeout.bat" batch file
Expected result: two instances of myapp.exe on different monitors opens up (run "withTimeout.bat" to see the "expected" result)
Actual result: two instances of myapp.exe on the same monitor opens up
Reproducible with: 2017.4.32f1, 2018.4.8f1, 2019.2.5f1, 2019.3.0b3, 2020.1.0a4
Workaround: run the unity instances with some delay (in batch its "timeout /t 1" command)
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- DisplayDialogComplex crashes with a long content string containg Cyrillic chars
- "Draw Additional Lights Shadowmap" calls increase when custom MaterialBlockProperty is used
- Crash on _platform_memmove when importing the "Dragon Crashers - URP 2D Sample Project" to a new 2D project
- "Shader is not supported on this GPU" warnings and and shaders are not loading when building the project for non-Chromium browsers
- [iOS][URP] The screen flickers and the "Execution of the command buffer was aborted due to an error during execution" error is thrown continuously
Resolution Note (fix version 2019.3):
Fixed in: 2019.3.0b12, 2020.1.0a12
IMPORTANT: the "adapter" command-line argument has been replaced with "monitor" in 2019.3 (for consistency across Desktop platforms); the behavior is exactly the same.
NOTE: This issue also occurs for other "screen" command-line parameters: screen-width, screen-height, and screen-fullscreen which are also addressed by the fix.
The problem is caused because these command-line arguments will set/update PlayerPrefs, i.e. these values are persisted and applied the next time the app is launched. So, the second instance of the app essentially "inherits" the values from the first process, causing it to ignore it's own command-line arguments due to a race-condition with PlayerPrefs updating logic. However, if the second process is delayed by a few seconds, the race-condition doesn't occur and the command arguments work properly.
The fix address the race-condition by setting "override" values when these arguments are passed in, forcing the runtime to apply the command-line values and ignore those stored in PlayerPrefs.
However, PlayerPrefs is updated by the command arguments, which is still a race-condition, and there's no guarantee as to which values will actually be saved. That is, the values from the first instance of the app may get saved to PlayerPrefs and not the values from the second instance as you might expect. Unity cannot solve this problem as the race occurs externally to the runtime, and so if the final state of PlayerPrefs is important, then you must stagger launching each instance of the app.