Multiple instances upon opening multiple Office Documents

Question

Starting with Version 16.0.8625.2121 of Office (tested with Word and Excel) - when you select multiple documents in the Explorer and hit Enter to open them, you will end up with instances to the count of the previous selected documents.

To reproduce do the following steps:

• Create 2 empty Excel Workbooks anywhere on your machine
• Select those 2 files
• Hit Enter
• Check Taskmanager and you will see 2 instances of Excel

In earlier versions than 16.0.8625.2121 you would end up with only 1 instance.

Tested with

• 16.0.4266.1003 - pretty old image we had around than we updated to newer versions with

  officec2rclient.exe /update user updatetoversion=16.0.xxxx.yyyy
  

Re-tested step by step with those new builds:

• 16.0.8431.2094
• 16.0.8431.2107
• 16.0.8528.2139
• 16.0.8528.2147

Before the obvious gets mentioned, DisableMergeInstance isnt set.

Is that a new "feature" or a bug? I believe its a bug.

Is there a way around it?

Further information:

We tested this behaviour with (always latest version)

• Windows 7 + Office 2016 - misbehavior happens
• Windows 10 + Office 2016 - misbehavior happens

Also checked older Office Version to make sure that this is a Office 2016 Thing

• Windows 8 + Office 2013 - doesnt happen
• Windows 7 + Office 2010 - doesnt happen
• Windows 10 + Office 2010 - doesnt happen
• Windows 10 + Office 2013 - doesnt happen

Solution 1

I apologize if I reiterate my explanations throughout, but I find this issue very complex so I tried to ensure it contextually makes sense to readers:

While it may not be known whether this is a bug or it was intended, we can force it to open in the "same" instance by using the Dynamic Data Exchange protocol (DDE) by creating a DDE message instead of the hard argument "%1" pointing to the file for that instance to open when executing the file. (Although, DDE is used even with the hard argument).

The DDE Message, in this case, is used to tell the program to open a file. For every file executed it actually creates a new instance every time. But when the DDE protocol is used, it firsts examines whether an instance is already created and if so it relays the DDE message to the first instance found and exits thus giving the illusion that all files open in a single instance as it is instantaneous.

Speculations

The issue of the files opening in multiples instances likely has to do with how much a single instance has already loaded when another instance is being called. The trend between the execution time difference of a first an second instance is as the time in between executions increases it tends to yield a single instance and as it decreases it tends to yield two instances. This suggests that the first instance must be loaded or "ready" to open a new file in that same instance if another file is executed, and if isn't it shall open the file with itself.

It seems when the file path is used as an argument to the program, it seems to follow this trend for only:

• Word 2016
• Excel 2016

When used as an argument for creating instances beyond the first instance if the first is ready (or if non-firsts see that is ready), the non-first instance seems to be able to relay the argument as a DDE message to the first.

However, if we execute the program and use a DDE message to open the file, it seems to follow the DDE protocol right away whether or not the first instance is ready to accept the DDE message via argument. Whether or not the first instance is ready likely depends if the non-first sees the first instance as ready, and if it doesn't it won't send the DDE message to the first, which seems to only occur when it opens via argument. The speculation of the non-first seeing the first as not "ready" or "non-existent" is suggested by the fact that DDE messages (from non-firsts) are accepted by the first when: the non-first is not executed via an argument concatenation "%1"; and it is told to open via a DDE message.

As such my speculation is: the code for these applications use some obscure method for determining whether another instance is "ready" and if so would then use the DDE protocol when an argument is used. This seems to use a different method than just when it receives the DDE protocol for determining if to send it to another instance. It would appear in effect the pseudocode was:

if(argrument.wasUsed()){
    // Office's obscure condition
    if(Office.thinksInstanceIsReady(anotherInstance)){
        // Use DDE Protocol
        if(anotherInstance.exists()){ // already knew that
            sendDDEmessage(anotherInstance);
            exitThisInstance();
        }
    } else {
        selfFollowDDEmessage(); // Leave open this instance
    }
if(givenDDEMessage()){
    // Use DDE Protocol
    if(anotherInstance.exists()){
        sendDDEmessage(anotherInstance);
        exitThisInstance();
    } else {
        selfFollowDDEmessage();
    }
}

There is no way of telling if this is a bug or it was intended to be obscure for a reason, without the programmers informing us.

The Resolution

We want to adjust the execution of certain file extensions to no longer send the file path ("%1") of the file being executed as an argument, but rather tell the program being executed to perform to the contents of DDE message, of which contains a request to open a file, which will relay it to an already existent instance if exists and if not use it itself. Which speculatively, will bypass the obscure requirements of these applications for another instance to be seen as "ready" if an argument to the file path is used.

These are all file extensions correlated to Class keys which shall be substituted with x:

For Word

FILEEXT          CLASS NAME (x)
 .doc*           Word.Document.8
 .docm†    Word.DocumentMacroEnabled.12
 .docx*         Word.Document.12
 .dot            Word.Template.8
 .dotm†    Word.TemplateMacroEnabled.12
 .dotx†         Word.Template.12
 .odt        Word.OpenDocumentText.12
 .rtf†             Word.RTF.8
 .wbk             Word.Backup.8
 .wiz             Word.Wizard.8
 .wll             Word.Addin.8

For Excel

FILEEXT             CLASS NAME (x)
 .csv*                Excel.CSV
 .ods       Excel.OpenDocumentSpreadsheet.12
 .slk                 Excel.SLK
 .xla                Excel.Addin
 .xlam†        Excel.AddInMacroEnabled
 .xld                Excel.Dialog
 .xlk                Excel.Backup
 .xll                 Excel.XLL
 .xlm              Excel.Macrosheet
 .xls*              Excel.Sheet.8
 .xlsb†     Excel.SheetBinaryMacroEnabled.12
 .xlshtml           Excelhtmlfile
 .xlsm†       Excel.SheetMacroEnabled.12
 .xlsx*             Excel.Sheet.12
 .xlt†             Excel.Template.8
 .xlthtml          Excelhtmltemplate
 .xltm†        Excel.TemplateMacroEnabled
 .xltx†             Excel.Template
 .xlw               Excel.Workspace
 .xlxml               Excelxmlss

* The most important/common file extensions that should be done as a minimum. Subjective.

† Secondary most important/common file extensions that should be done for as a minimum. Subjective.

These lists can be replicated through command-line: assoc | findstr Word replacing Word with the official shortened name (case-sensitive).

All of which you have the option to do if you feel it is necessary. If the more you want to do you might want to follow the optionable steps which I shall provide, which should reduce the work needed.

You shall follow the following instructions for every registry key below replacing the x with the corresponding Class(es) of your choice(s):

• HKEY_CLASSES_ROOT\x\shell\Open
• HKEY_CLASSES_ROOT\x\shell\OpenAsReadOnly

(Ex : HKEY_CLASSES_ROOT\Excel.Sheet.12\shell\Open)

Once again, the OpenAsReadOnly key, is optionable this will ready when the file is executed such that it would be read-only.

A small precaution - a backup

To best remember what the registry values were before modification, you may want to go to right-click the key branch HKEY_CLASSES_ROOT, and under the context menu click "Export" and save the Registration File to a location. In case Doc Brown says "We need to go back," you can just import the registry key by executing it and following the instructions.

Alternatively, you can also run this so you remember what the command values and Class names were to fix small mistakes with:

assoc>>fileexts.txt which can be filtered using type fileexts.txt | findstr Word

ftype>>classnames.txt which can be filtered using type classnames.txt | findstr Word

Instructions

These shall be followed for every key value listed above, as you desire to do.

Enter unto your favorite registry editor or regedit and go to the Class you wish to modify.

Enter into the key called command, right-click the (Default) value, and click "Modify" under the context menu.

Currently set should be what was executed by ftype | findstr Word

Change it to remove the direct arguments at the end of the value, including the space, to become:

• "C:\Program Files\Microsoft Office\Root\Office16\EXCEL.EXE"
  (For Excel 64-bit)
• "C:\Program Files\Microsoft Office\Root\Office16\WINWORD.EXE"
  (For Word 64-bit)
• "C:\Program Files (x86)\Microsoft Office\Root\Office16\WINWORD.EXE"
  (For Word 32-bit)
• "C:\Program Files (x86)\Microsoft Office\Root\Office16\EXCEL.EXE"
  (For Excel 32-bit)

Enter into the key called ddeexec (if it does not exist, create the key) which would be beside the command key, right-click the (Default) value, and click "Modify" under the context menu, and set the value to become:

• [REM _DDE_Direct][FileOpen("%1")] - (For Word)
• [open("%1")] - (For Excel)

Underneath ddeexec create a new key called topic (if it does not exist), right-click the (Default) value, and click "Modify" under the context menu, and set the value to become system (if not already).

After the modifications you may have to refresh shell32.dll by running this with an elevated Command Prompt or shell after creating these changes to the registry:

regsvr32 /i shell32.dll

This has been tested on a Windows 10 Office 2016 Version 16.0.8625.2127

Alternative shortcut

You can also go to the key for file extensions (such as HKEY_CLASSES_ROOT\.xlsx) and modify the "(Default)" value to a singular class, this approach, if followed, can point multiple file extensions to the same Class value (such as Excel.Sheet.12) which you only have to modify that class once with the DDE Message. If you do this one should also re-name all reiterations of the Class name inside that registry branch. However, this way is not recommended, as it could easily break, and should be done if you were to do all file extensions to save time.

Sidenotes:

The /o argument is an argument for URLs, so isn't a big concern in losing this functionality as it rarely is passed. However, if you so wish, you can try and leave this part of the argument on when adjusting the (Default) values.

I am considering to make this a community wiki, since it is very speculative and also unfinished (if Word & Excel were not the only ones). Please comment an opinion on this.

Solution 2

In addition to the excellent answer by @El8tedN8te, I remark that for Excel it is not necessary to modify the ddeexec registry key.

It is enough to set the value of the (Default) item to :

"C:\Program Files (x86)\Microsoft Office\Root\Office16\EXCEL.EXE" /dde "%1"

This by my tests ensures that only one instance of Excel is executed.

Comments

[El8dN8]

This does not answer the question because even the link you provided says when you open two excel worksheets one after the other, "On the Processes tab scroll down until you see Excel.exe. Be aware that although you opened two occurrences of Excel, the two workbooks are contained in the same single instance of Excel." The way the OP creates two instances (with the same method as Microsoft's) contradicts the statement that "there is no MDI compatibility option in Excel" because multiple document interfaces (instances) are appearing, not within the same instance it is supposed to be.

[Rand Random]

As @El8tedN8te pointed out I am talking about 2 instances (2 processes) and not 2 windows.

[El8dN8]

On mine, this method did not work to no avail, it didn't run in a single instance. I tried pretty hard to prove myself wrong. I restarted, double checked I was using the right Class name and extension, flip-flopped your arguments, and killed "C2R" .exe. In fact did the opposite, even if they weren't opened simultaneously, the extra argument made them stay separate instances, which is acknowledged here: social.technet.microsoft.com/Forums/office/en-US/…

[harrymc]

@El8tedN8te: I don't know what the difference is between our two computers. Maybe in menu File > Options > Advanced, under General, option "Ignore other applications that use Dynamic Data Exchange (DDE)". Your link confirms that /dde should force a single instance.

[El8dN8]

I don't know if I was delerious when I read that link... ha... ha... Yes, I checked that setting... worth looking into to why mine is behaving differently. If my PC is wrong, my speculation is wrong. May I ask, your office version?

[harrymc]

@El8tedN8te: Version 16.0.8625.2121.

[El8dN8]

I would like to correct my earlier comment, the quote provided is actually correct. So disregard my entire last sentence... of my last comment. I was being presumptuous.

[Rand Random]

On my machine it is also not working, just like @El8tedN8te.

[harrymc]

@RandRandom: Strange, as it should work according to the docs, and it does work as documented on my computer. It may have something to do the versions of Windows/Office or installed add-ons. But the comments here are not the place for investigation.

[m2cit]

It's fine, @El8tedN8te. I was wondering what was wrong in the quote