2

We have a .Net 4.0 executable (MyProg.exe) and associated dlls that are deployed on a network share using XCopy. MyProg.exe and its dlls are all unsigned.

We have them installed on the network share so multiple users can use the same version of the program and to ease updating the program. This worked well for many of our customers for many years now.

For a recent customer, a folder on Windows Server 2012 Virtual Machine is shared as a network folder. Users run the program from another terminal server (Windows Server 2012).

When we updated the MyProg.exe (to version 2.0 from 1.0), the terminal server does not run the new executable until it is restarted. It continues to load version 1.0 even though that exe is no longer available. It appears to be running a cached version of MyProg.exe V1.0.

  1. The steps I tried:
    1. Close all instances of the program
    2. Copy the new MyProg.exe to the folder and overwrite the files (Updated exe version from 1.0 to 2.0)
    3. Verify version 2.0 of the MyProg.exe from its Properties >> Details page both from file-server and terminal server
    4. Verify that the MyProg.exe V2.0 runs when executed from the file-server using shortcut file (target: \\Server\MyProg\MyProg.exe)
    5. Run the same shortcut file (target: \\Server\MyProg\MyProg.exe) from terminal server and MyProg.exe V1.0 starts
    6. Rename \\Server\MyProg to \\Server\ MyProg1 and confirm that terminal server can not run the shortcut because that folder no longer exists.
    7. Create a new shortcut file (Traget: \\Server\MyProg1\MyProg.exe) and confirm that MyProg.exe V2.0 runs on the client
    8. Rename the folder \\Server\MyProg1 back to \\Server\MyProg and running the original shortcut file continues to load MyProg.exe V1.0 until the terminal server is restarted.
    9. I verified that offline files is disabled on terminal server
    10. I verified that I can not overwrite the MyProg.exe executable when the program is running on Terminal server.

What else can I check to troubleshoot why an older version of the executable is being executed even when that file no longer exists?

Kishore A
  • 141
  • 1
  • 6

1 Answers1

1

Contacted Microsoft Technical Support team. They mentioned it could be caused by these settings for SMB. We modified these settings and will keep an out during the next update.

http://technet.microsoft.com/en-us/library/ff686200(v=WS.10).aspx

The settings from the above link did not work.
More details that helped us to figure out the issue: Client Computer is a Windows Terminal Server

This knowledge base article gives more information in this regard:
https://support.microsoft.com/kb/2536487

Applications may crash or become unresponsive if another user logs off Remote Desktop session in Windows Server 2008 or Windows Server 2008 R2

Symptoms:

When running an application from a mapped drive, the application may become unresponsive or crash for a user (or multiple users) when another user logs off. For example:

  1. One server is a file server and another is a Remote Session Host server (terminal server).
  2. A folder on the file server is mapped for use by remote users connecting to the RDS server.
  3. An application on the mapped share is launched by multiple users.
  4. One user logs off, and this causes the other users of the application to experience an application crash or unresponsiveness.

Specifically, the behavior is caused when either the first user or the last user of the application logs off, depending on version. Windows Server 2008 will experience this issue when the first user logs off; Windows Server 2008 R2 will experience this issue when the last user logs off.

Cause:

This occurs due to the way in which the redirector handles the FCB (File Control Block) for the binary in question. In Windows Server 2008, the FCB is owned by the user who first opened the file and this FCB is used by subsequent users. When the first user logs off, the FCB is orphaned which caused the subsequent users of the application to crash or become unresponsive. In Windows Server 2008 R2, the FCB is owned by the last user to open the file and prior users experience the issue if the last user logs off

Workaround :

Install the application locally on terminal server instead of on a network share

Kishore A
  • 141
  • 1
  • 6