none
Process crash because of unloaded dll caused by disconnection of another Terminal Service session using same application concurrently RRS feed

  • Question

  • Hi,

    during some Remote Desktop Services tests on Windows 2008 R2, I discovered following problem that does not appears in previous version of Windows 2008:

     

    When a Terminal Services session execute a dll based application (for example MS spyxx.exe) from a mapped network drive and a second session execute the same app and then disconnect from session without closing it, the app running in the first session gets the loaded dll from network drive unloaded. Any further use of the application drive it to a crash.

     

    The problem is very bad, because inhibits the concurrent use of same application from a network drive.

     

    The problem manifest itself only with following conditions:

    -          Windows Server 2008 R2 base or Service Pack 1 with installed Remote Desktop Services.

    -          The various Terminal Services session have a drive (same letter or not) mapped to the same UNC share.

     

    The problem does not happens:

    -          On previous version of Windows 2008 (32/64 bit).

    -          If the sessions execute the application directly from an UNC path like \\serverName\shareName\pathToApp\Appname.exe .

     

    Steps to reproduce the problem:

    -          Install a copy of Windows 2008 R2 Standard (download a copy from http://technet.microsoft.com/en-us/evalcenter/dd459137.aspx)

    -          From Administrator session install Remote Desktop Services. From Server Manager click on ‘Add Role’, on 'Server Roles' select 'Remote Desktop Services',  on 'Role Services' select 'Remote Desktop Session Host', on 'Authentication Method' select 'Do not require Network Level Authentication', on 'Licensing Mode' select 'Per User', on 'User Groups' add a previous created user  'UserA', on 'Client Experience' click ‘Next’, install, accept restart, reconnect and wait for installation completion.

    -          In Administrator session download ProcessExplorer from http://download.sysinternals.com/Files/ProcessExplorer.zip, expand the zip in a folder and execute procexp.exe. On menu 'View' -> 'Select Columns...' select 'User Name' and 'Image Path', on 'DLL' tab select 'Path', click ‘OK’. Press Ctrl-D keys to display lower dll’s pane and sort by path clicking on ‘Path’ header column.

    -          Download Microsoft Spy from http://cid-539d62829af123fb.office.live.com/self.aspx/.Public/spyxx.rar , expand the rar content in a network share called ‘myShare’.

    -          Map drive Z: on the network share 'myShare', for example.: \\serverName\myShare and execute z:\spyxx\spyxx.exe.

    -          On ProcessExplorer select spyxx.exe process; on the lower pane you can see the set of dlls loaded from the network drive, for example \device\mup\servername\myshare\spyxx\spyxxhk.dll .

    -          Open a new Terminal Services session as ‘UserA’, map drive Z: on same network share 'myShare' (as done for Administrator), execute z:\spyxx\spyxx.exe .

    -          Disconnect ‘UserA’ session WITHOUT closing spyxx.exe application before.

    -          Go to the Administrator session, on ProcessExplorer you can see that from the spyxx.exe application has been removed following dlls loaded from network drive: mfc71u.dll, msvcp71.dll, msvcr71.dll, spyxxhk.dll . In case of different drive letters mapped on same share, also the spyxx.exe is unloaded from the dll view in ProcessExplorer.

    -          To further confirm the bug, switch to spyxx.exe application, select menu Spy -> Processes and you will get a crash.

     

    Have someone find same problem and found a solution?

     

     

    Wednesday, January 18, 2012 9:11 AM

Answers

  • Thank you for the information, Olivier.

    In the meantime I discovered a workaround exposed below:

     

    While waiting for a Microsoft fix, you can use this workaround on the server offering the share through the use of Distributed File System. I found that mapping the drive using a DFS share works well – the problem never happen.

    If the share is on a Windows 2008 R2 server follow this instructions to install the DFS role:

    - From 'Initial Configuration Tasks' click on 'Add roles'

    - Click 'Next;

    - Select 'File Services', click 'Next'

    - Click 'Next;

    - Select 'File Server' and 'DFS Namespaces' roles, click 'Next';

    - Accept the default namespace, click 'Next'

    - Accept default stand-alone namespace, click 'Next'

    - Click ‘Add…’, click ‘Browse…’,  click ‘Show Shared Folders’,  click ‘New Shared Folder…’, on ‘Share Name’ textbox write ‘myShare’,  click ‘Browse’ to select local path of shared folder,  create a folder ‘myShare’ on C: and select it, click ‘OK’, on ‘Shared folder permissions’ options choose one, click ‘OK’, click ‘OK’, you will see ‘myShare’ under ‘Namespace1’, Click 'Next;

    - Click 'Install’ and wait for installation;

    - Click 'Close’;

    Now you have installed the DFS role and you should be able to map a drive from your terminal service sessions using the ‘\\serverName\Namespace1\myShare’ with a command like ‘net use * \\W2008R2\Namespace1\myShare’ .

     

    Carlo

    Thursday, January 26, 2012 11:44 AM

All replies

  • Hi,

     

    If you are using Windows XP & Vista for you client, you should install the RDC 7.0.

    Remote Desktop Connection 7.0

    http://support.microsoft.com/kb/969084/en-us

     

    Make sure that Windows Terminal server and client PC's NIC driver has been correctly installed and has been upgraded to the latest version.

     

    Do you have install any antivirus software? Please try to disable the antivirus software to see if the same issue still exists.

     

    Some cases, if the UAC affect the production environment, we can also choose to turn off it.

    You can open the Control Panel and click User Accounts in RDS 2008 R2 server, then click the Change User Account Control setting, dropped to the lowest turn off UAC. Press OK.

     

     


    Technology changes life……
    Monday, January 23, 2012 3:33 AM
    Moderator
  • Hi Dollar Wang,
    as client software, I am already using Remote Desktop Connection 7.0 version 6.1.7601.17514 from a Windows 7 sp1 32bit;  on the 2008 server have sp1 installed with all latest updates; no antivirus installed, UAC already disabled.

    Problem persists.

    You can easily reproduce the problem also in a 2008 r2 virtualized environment - I use Vmware ESXi 4.1 - and the problem manifest itself also there.

    Carlo

    Monday, January 23, 2012 9:16 AM
  • Hi,

    This problem is quite similar to the one describe in http://support.microsoft.com/kb/2536487. According to http://www.bearnakedcode.com/2011/06/win-2008-terminal-server-network-app.html, there is little chance that a fix will arrive anytime soon. This blog post also describe some possible workaround like the UNC path one. The Microsoft answer seems "do not run applications from a shared drive anymore... or use Webdav" (see above kb article).

    Good luck.

    Olivier


    • Edited by oco2 Thursday, January 26, 2012 12:47 AM Replace page addresses with links
    Thursday, January 26, 2012 12:40 AM
  • Thank you for the information, Olivier.

    In the meantime I discovered a workaround exposed below:

     

    While waiting for a Microsoft fix, you can use this workaround on the server offering the share through the use of Distributed File System. I found that mapping the drive using a DFS share works well – the problem never happen.

    If the share is on a Windows 2008 R2 server follow this instructions to install the DFS role:

    - From 'Initial Configuration Tasks' click on 'Add roles'

    - Click 'Next;

    - Select 'File Services', click 'Next'

    - Click 'Next;

    - Select 'File Server' and 'DFS Namespaces' roles, click 'Next';

    - Accept the default namespace, click 'Next'

    - Accept default stand-alone namespace, click 'Next'

    - Click ‘Add…’, click ‘Browse…’,  click ‘Show Shared Folders’,  click ‘New Shared Folder…’, on ‘Share Name’ textbox write ‘myShare’,  click ‘Browse’ to select local path of shared folder,  create a folder ‘myShare’ on C: and select it, click ‘OK’, on ‘Shared folder permissions’ options choose one, click ‘OK’, click ‘OK’, you will see ‘myShare’ under ‘Namespace1’, Click 'Next;

    - Click 'Install’ and wait for installation;

    - Click 'Close’;

    Now you have installed the DFS role and you should be able to map a drive from your terminal service sessions using the ‘\\serverName\Namespace1\myShare’ with a command like ‘net use * \\W2008R2\Namespace1\myShare’ .

     

    Carlo

    Thursday, January 26, 2012 11:44 AM
  • Hello,

    has somebody experience with the dfs workaround?
    Does this work?
    We have an applications which is installed in a network share and sometimes, when the applications has crashed  in a session other seesions could not open the application.

    After killing the processes in the session where the app crashed, other users can use the application again.
    Is it enough to create one DFS share? Does every user need own share?

    Thank you

    Regards

    Monday, February 13, 2012 3:54 PM