Sublime Forum

Too many ST windows open + admin/non-admin problem

#1

Hi,

TL;DR: there is a bug on Windows, steps to reproduce:

  • start ST4 from an admin software (example: from cmd.exe which has been started as admin): it shows (ADMIN) in the ST title bar

  • double-click on test.txt on Desktop : it opens a new ST window (non admin)

  • double-click on test2.txt on Desktop : it opens a third ST window (non admin)

…

  • double-click on test9.txt on Desktop : it opens a 10th ST window (non admin)

How to have only 1 or 2 windows, and new tabs instead?

Note: if you reproduce these steps avoiding step #1 (starting an (ADMIN) ST window first), then at the end of step #10, you have only one single window, with many tabs, as expected.

How to solve this problem?

More context:

In my setup, files are opened in ST4 from various places:

  • from the Windows File Explorer, for example double clicking on a .txt file on Desktop (then ST is NOT started as admin) (.txt file are associated with Sublime)
  • from “Everything” (which in my setup runs as admin), then ST opens a new window “ADMIN” to open the files
  • from Autohotkey (it HAS to run as admin, if not => it wouldn’t catch keyboard shorcuts when you are using an admin software / when an admin software has “focus”), then ST opens a new window “ADMIN”.

So logically, at the end, there should be maximum 2 ST windows:

  • 1 non-admin ST window
  • 1 admin ST window

But for an unknown reason, every time I double click on a new .txt file (either in Explorer or Everything or elsewhere), sometimes it opens a new window instead of a new tab.
At the end, I end up with 5 or 10 different ST windows, with the same files opened! It’s totally unusable, you don’t know which window has the “latest” version of a file.

I already use "open_files_in_new_window": false but without success.

  • how to avoid having more than 2 ST windows (one for admin, and one for non-admin) when you open new files from Explorer (with filetype association)?

  • is it possible to have only 1 window (either admin or non-admin), and then each time you open a new file (from anywhere, from a non-admin like Explorer or admin software like Everything), it adds a new tab in the single ST window, and not open a new n+1 window?

Linked: post 1 post 2 post 3

0 Likes
#2

Anyone an idea?

When opening multiple files from both admin/non-admin, you end up with dozens of ST windows which is really hard to work with…

0 Likes
#3

By default ST relies on a single process running. The way how Windows runs the process in a different user context - probably isolating it from others - with same user profile might confuse ST as those processess very likely access (read & write) same session file containing all state.

I can confirm this behavior but only sublimehq can investigate and probably improve behavior.

You may want to file a bug report at https://github.com/sublimehq/sublime_text/issues to increase chance for sublimehq to look into.

1 Like
#4

I can confirm this behavior but only sublimehq can investigate and probably improve behavior.

Thank you for confirming.

If during your session, you open just one file in ST “as admin”, then after this, everything you open in ST will have a (n+1)th window…

Conclusion: if you open a file as admin in ST once, then your workflow becomes totally unusable :grimacing: because with 12 windows you are totally lost. I confirm it’s impossible to work on the long term.

How do other people handle this problem?

0 Likes
#5

Given this is the first time such issue is raised, outlined use case is probably rather special and unlikely.

I tend to advice to look for alternatives which don’t require applications to run in admin mode to do user-level tasks as those setups undermine all security messures taken by OS.

0 Likes
#6

I have read multiple forum posts in which people have similar problems, see for example 4180 by default opens in ADMIN mode - Technical Support - Sublime Forum, among lots of others.

0 Likes
#7

That issue and likely others are unrelated. Those issues showed up when ST started showing that it has administrator privileges; beforehand it was not easy to tell so people did so accidentally.

0 Likes
#8

@bschaaf can you confirm you also have this:

  • run ST4 as admin (e.g. ran from admin cmd.exe or from an Autohotkey script - necessarily in admin: if not, it wouldn’t catch keystrokes when an admin program has focus)
  • run ST4 from desktop by clicking on test2.txt
  • run ST4 from desktop by clicking on test3.txt
    …
  • run ST4 from desktop by clicking on test10.txt

=> 10 windows of ST4 instead of 2 (1 admin, and 1 non-admin with 9 tabs)

I have seen quite a few people having same bug in some reddit posts etc.

Is there an easy workaround @bschaaf with a command-line parameter maybe, to avoid spawning new windows?

0 Likes
#9

My assumption is that it’s spawning new application instances, which can’t be worked around. I’ve put this issue in my backlog.

0 Likes
#10

ST4 will spawn new instances after opening one as admin, but as soon as you close the admin instance, it will start reusing the most recently created instance, and creating a new tab within that instance.

Whatever code ST4 is using to find the currently running instance (usually by a mutex) probably finds the first instance, recognizes that it is running with admin privileges, and then starts a new instance with non-admin privileges. It probably isn’t looking for a non-privileged instance after the first mutex/instance check identifies the privileged instance. This should be a relatively straightforward fix.

0 Likes
#11

Whatever code ST4 is using to find the currently running instance (usually by a mutex) probably finds the first instance, recognizes that it is running with admin privileges, and then starts a new instance with non-admin privileges. It probably isn’t looking for a non-privileged instance after the first mutex/instance check identifies the privileged instance. This should be a relatively straightforward fix.

Yes, at startup, it likely checks for the existence of a named pipe like \Device\NamedPipe\SublimeText.* . If found, it attempts to send a command through it to open a new file. However, if the existing pipe was created by an elevated (admin) instance, a non-admin ST process won’t have permission to write to it. As a last resort, ST then opens a new window.

Probable (easy) fix:

  • enumerate the next \Device\NamedPipe\SublimeText.* named pipes if it fails with the first one.

or

  • enumerate all these named pipes, and:

    • if the new ST instance is non-admin, let it send commands to non-admin-ST-named-pipes only
    • if the new ST instance is admin, let it send commands to admin-ST-named-pipe if it exists, and if not, to a non-admin-ST-named-pipe

or

  • distinguish names: \Device\NamedPipe\SublimeText.1234 vs. \Device\NamedPipe\SublimeText_admin.1234

Do you think one of these could work @bschaaf @doomdog?

0 Likes
#12

@blexi - It seems ST only creates one Named Pipe, no matter how many instances are running (admin or non-admin). The name is the same in either case:

\\.\pipe\Sublime Text.121e5b2d4b6565b266745324c25e27d6

The initial workflow issue that you reported isn’t 100% accurate - there are multiple variations here:

Standard flow:

Open a file:  ST process (1) and window are created
Open a file:  another tab is created in the first ST window
Open a file:  another tab is created in the first ST window

Admin flow #1:

Open a file as Admin:  ST process (1) and window with [ADMIN] are created
Open a file:  ST process (2) and window are created
Open a file:  ST process (3) and window are created
Open a file as Admin:  another tab is created in the first [ADMIN] window
Open a file:  ST process (3) and window are created

Admin flow #2:

Open a file:  ST process (1) and window are created
Open a file as Admin:  ST window created, without [ADMIN] tag.
Open a file:  another tab is created in the second ST window
Open a file:  another tab is created in the second ST window
Open a file as Admin:  another tab is created in the second ST window
(only one process is created overall)

Offhand, I would say that both admin flow #1 and #2 are incorrect but at least flow #2 is more consistent.

Without knowing the underlying details of how ST decides to start a new process, or window, it is going to be impossible to suggest a fix for this issue.

0 Likes
#13

generally there should be no need to “fix” anything - just always start ST as a non-admin, and allow it to prompt for elevation when you need permission to save something adminy

Otherwise all plugins etc also operate as admin - how well do you audit your plugins?

0 Likes
#14

@kingkeith Yes, there is a need to fix something, because the admin workflow #1 I listed above is objectively wrong. This isn’t something I would consider a high-profile bug, since it is easy to work around once you understand the behavior - but it is wrong and needs to be looked at, eventually.

As far as auditing plugins, I generally browse through the github repos for my plugins, if they’re listed, before I’ll install them. Most people don’t do that, because it takes a lot of time.

Your comment brings up another issue – maybe starting ST with admin permissions should automatically disable plugins, but still allow you to enable them one by one in an admin session. That could be a nice enhancement. ST already has something like this where you can start in safe mode - but maybe it should be automatic “safe mode” for admin…

0 Likes
#15

This is not correct in my opinion, there is definitely a need to fix at least this:

Open test1.txt as admin. Open test2.txt as non-admin, …, open test10.txt as non-admin => there are 10 windows. There should normally be only 2 windows.

just always start ST as a non-admin, and allow it to prompt for elevation when you need permission to save something adminy

I don’t think it is easily possible. When an elevated process launches a new process in Windows, the new process inherits from the elevated properties. As an example, it is non-trivial to launch ST as non-admin from an Administrator cmd.exe. All the common solutions (runas /..., __COMPAT_LAYER set to RunAsInvoker, etc.) don’t seem to work. And sometimes an elevated process needs to be able to launch ST (for example AutoHotkey, but there are many other examples depending on your workflow).

0 Likes