Second instance of Word opened from Access arises security warning? (1 Viewer)

[lauro]

Hi,
I have a new and very strange problem arising from Word and Access interop.
Never noticed something similar before. Now I'm using Microsoft 365

I an Access form I have only a text control where I can type the name of the word file I want to open and a buttons that opens it.

The first time I click the button everyting fine, as expected.
The second time (the first word file is still opened) the following security warning pops up.

The folder where the files are is a trusted folder!
Allowing all macro in Word Option is not useful!
The file are based on a template with only one macro.

I don't know what to think!


The code run from button click is the following:

Private Sub cmdBtWord_Click()
Dim objWordApp As Word.Application
Dim sFileName As String

sFileName = Me.txtFileName
On Error Resume Next
Set objWordApp = GetObject("Word.Application")
If Err.Number <> 0 Then Set objWordApp = CreateObject("Word.Application")
On Error GoTo 0
With objWordApp
.Visible = True
.Activate
.Documents.Open sFileName
End With
Set objWordApp = Nothing
End Sub

 

[The_Doc_Man]

Documents.Open method (Word)

Office VBA reference topic

learn.microsoft.com

Take a look at the discussion of the "Revert" option. What is the content of sFileName when you click the button a second time? Is there a chance that you are opening the same name twice? Or (see next paragraph) that the name is blank?

Also, note that the name that is called out by the error begins with a tilde (~), which is a sign for a file opened temporarily. I am not sure because to be honest, it has been a while since I worried about this, but that name LOOKS like the name of the temporary file that is opened when creating a new file without naming it first on the command line. You don't have to name a file or specify its path until you actually save it. So if that is a temporary file, it is telling you that the temporary file can't be opened. That path that contains \<username>\AppData\Local\ is in your personal profile in a temporary area created by installation of Office, so probably ISN'T in a trusted location.

Also, in your code, you open the word application but then set the object variable to Nothing without first CLOSING the Word file. So that means you probably have a "ghost" copy of Word still active sitting in the background. You could confirm this via Windows Task Manager, "Processes" tab. If Word is still hanging around, its files are still "Open for Modify" (one of the several possible file locking states) and thus cannot be touched by another process until you resolve the Word issue. And it IS another process because when you create an application object as you did, that causes a child process to be created within your session's parent process. (It can't be part of the parent session directly because Access is using the memory resources of that process.)

 

[Josef P.]

I had the same problem. Deleting the Normal.dotm helped - renaming so the file still remains available.
The problem was that when Word was opened, it created any temp files in the folder shown in #1. It locked itself because that folder cannot be defined as a trusted location.

 

[lauro]

Hi, thanks to both of you.
The_Doc_Man said:
> Take a look at the discussion of the "Revert" option.
Where is the discussion? It's not in the link provided.

I checked carefully and debugged:

• I removed the Set objWordApp = Nothing
• The file names are different.
• The second time the Set objWordApp = GetObject("Word.Application") never finds a Word instance opened, but Windows Task Manager sees it, and always a new instance is created.
• Yes, the file opened is a temporary one and that folder is not trusted; but why Word is not opnening the file the code says to open! i.e. .Documents.Open sFileName ! Debugging I can see in sFileName the right name.
• Deleting normal.dotm didn't help.

Josef P. said:
> folder shown in #1.
I don't understand.

I remembering reading somewhere that all the files opend by Word are "temporary", even if that is transparent to the user...

 

[lauro]

Hi, an update.

I created a UserForm in Excel and used the same code.

Same problem!!!

 

[lauro]

A little more information.
If the files opened are only based on "normal.dotm" everything is fine.
If are based on "my.dotm" with only Debug.Print Now() in Document_New and Document_Open the problem arises.
If push the button "Disabilita macro" [disable macros], The file opens; it's the rigth one; it has the correct name.

Until now I was using Windows 11 Pro Build 22631.2715 and Word Microsoft 365 Version 2310 (build 16924.20150).
Now I tested same files, same "*.dotm" on my laptop with Windows 10 Home Build 19045.3570 and Word Microsoft 365 Version 2309 (build 16827.20166). And I had this even stranger behavior on the second file

• Again the Word instance is not found; it takes quite a lot to execute Set objWordApp = CreateObject("Word.Application")
• If I then look the Windows Task Manager, I found one normal instance of Word, but the 2 more instance both with a security warning that links to THE NEFORIUS POP UP MESSAGE.
• But if I ignore the Windows Task Manager and I continue to debug the code in Excel when I reach the instruction .Visible = True it trows the error
• 

I don't know what to think.

 

[The_Doc_Man]

Where is the discussion? It's not in the link provided.

"revert" is an optional parameter in the .Open method. It might not be relevant, but it seems to relate to file readability.

I removed the Set objWordApp = Nothing

My complaint was more that you should have closed the file before erasing the object. That is what leaves it "dangling." ... As in this next quote.

if I then look the Windows Task Manager, I found one normal instance of Word, but the 2 more instance both with a security warning that links to THE NEFORIUS POP UP MESSAGE.

I continue to debug the code in Excel when I reach the instruction .Visible = True it trows the error

The error is telling that the object holding that property (in this case, .Visible) is not properly defined or is in a state where that action makes no sense. (Like it is closed already.)

 

[lauro]

"revert" is an optional parameter in the .Open method. It might not be relevant, but it seems to relate to file readability.



My complaint was more that you should have closed the file before erasing the object. That is what leaves it "dangling." ... As in this next quote.





The error is telling that the object holding that property (in this case, .Visible) is not properly defined or is in a state where that action makes no sense. (Like it is closed already.)

Why 2 instances of Word with the problem?

 

[The_Doc_Man]

I am going to take this question as needing a technical response. If I have misunderstood your intent, I apologize.

When you log in to a session on your workstation, you create a "process" - the Windows term for a software structure that owns resources like control devices, free memory, and memory space. Memory space is the virtual address range in use in that process. Not all memory spaces are equal in the world of Windows.

When Windows operating system (O/S) wants to execute some code, it can only do so in the context of a process. In that case, the process can ask for a CPU resource. This CPU resource cannot normally be locked down to a single process; it is ALWAYS shared round-robin style in any O/S below the level of Windows Server or any Windows-related virtual machine platform. (Not going to swear that Windows Professional can't assign a specific CPU to a process using the Set Affinity commands, but it is rare.)

When you create an application object from Access, whether it is Word, Excel, or Outlook, you must create another process, in this case a CHILD of the session's primary process. That is because Access and the application object BOTH need memory and both need specific ranges of memory space that both will occupy - but only one of them can win the battle for memory if you have a single process. With a child process, you can have a separate memory allocation and memory space allocation for each child. This a key point: Because of memory conflicts if you DIDN'T create a new process, you could not run multiple programs simultaneously. If you DO create a new process, you have no memory and memory space conflicts.

When you create that app object, it occupies memory in its own little process. The method of creating that process makes it look to the parent process for all control inputs and all resulting outputs. There are ways to make the app object open up on its own for mouse, keyboard, and display interaction, but it is possible to completely control that object invisibly through Access. It just depends on the way you create it. In Outlook, for example, you open an "inspector" object. Don't ask me where they get their names.

When you create an app object and DON'T set it up for direct user control, it becomes a detached process. But it IS in a process of its own. Which means it can live on even if the process that created it now exits. For that reason, it is HIGHLY recommended that you should remember to tell the application object to .QUIT when you are finished with it. But some objects won't quit unless you first CLOSE any files you opened using that object. This is because processes with open files cannot close. All processes undergo a "process rundown" that assures that all I/O channels are closed. But first you have to tell the process to do that. Erasing the app object by setting it to "NOTHING" does not tell the object what to do about its still-open file. Therefore, when dealing with app objects, ALWAYS close what you open.

There are two ways to read your question. The other way is "Why does this happen on more than one version of Word?" The answer is that it is because of faulty code that you use to manipulate the object without cleaning up after itself. This is not a bug in Word... it is a bug in your code. ANY version of those object utilities would have the same problem if you approached the problem in the same way.

 

[lauro]

Hi The_Doc_Man, thanks for your answer.

Still, I don't understand why this simple code, used before thousand of times, is causing this problem now when the files based on a very simple template are opened.
The Word files, the Word template, the Access or Excel mother application are all in a trusted folder.
Where the following code is faulty?

Private Sub cmdBtWord_Click()
Dim objWordApp As Word.Application
Dim sFileName As String

sFileName = Me.txtFileName
On Error Resume Next
Set objWordApp = GetObject("Word.Application")
If Err.Number <> 0 Then Set objWordApp = CreateObject("Word.Application")
On Error GoTo 0
With objWordApp
.Visible = True
.Activate
.Documents.Open sFileName
End With
End Sub

 

[The_Doc_Man]

OK, this code has worked for a long time. Check the Windows Update history to see if you have recently had an Office update. It can change the behavior of something that worked for years because Microsoft thinks there is a hole somewhere in security.

I have to ask... are you leaving the Word app open for direct user interaction here? Because based on the code snippet you showed in #10, when you execute the END SUB line, the object variable goes away as though you set it NOTHING programmatically.

 

[lauro]

OK, this code has worked for a long time. Check the Windows Update history to see if you have recently had an Office update. It can change the behavior of something that worked for years because Microsoft thinks there is a hole somewhere in security.

I have to ask... are you leaving the Word app open for direct user interaction here? Because based on the code snippet you showed in #10, when you execute the END SUB line, the object variable goes away as though you set it NOTHING programmatically.

I removed the Nothing and the result is the same.
Yes, I leave the files opened for the user

 

[The_Doc_Man]

I removed the Nothing and the result is the same.

Yes, that is actually to be expected since the object is defined in the context of a subroutine. Variables declared in that context exist only for the duration of that sub's execution. When it hits either END SUB or EXIT SUB, the temporary declarations are revoked and their memory is reclaimed. In essence, the EXIT SUB dereferences all objects declared in the routine, so ... no cleanup. Note, however, that if you had NOT made Word available to the users it WOULD have been "dangling" and thus harder to deal with.

 

[lauro]

Taller in StackOverflow spotted the error in my code.
The instruction:
Set objWordApp = GetObject( "Word.Application")
should be:
Set objWordApp = GetObject( , "Word.Application")
That was the reason why the open instance of Word was never intercepted!
Thank anyway to all,
Lauro

 

[lauro]

Taller in StackOverflow spotted the error in my code.
The instruction:
Set objWordApp = GetObject( "Word.Application")
should be:
Set objWordApp = GetObject( , "Word.Application")
That was the reason why the open instance of Word was never intercepted!
Thank anyway to all,
Lauro

Still I would like to know why opening several instances of Word should create the security problem!