CreateFile with read flag and impersonation takes 30 seconds - how to investigate? RRS feed

  • Question

  • Hi,

    I have a very strange problem - we have an application that operates with a  file share which is visible to regular users, but they don't have any access rigts with their AD account except "list folder contents" and "read data". "read data" doens't give the ability to actually read the file.

    The applicaiton uses impersonation to access these files. So the app runs with regular user's right, but when the user causes the application to copy a file from the file share associated to the application to a local temp folder it impersonates another AD account.  

    That is a regular user.... it can do an interactive logon

    After copying the file to %temp% the impersonation goes back to the regular user account that started the application.

    The regular user has only "list folder contents" and "read data" access right at the document share, the other AD account has "read, create, write, delete" access rights.

    The logic in that proces seems to work as:

    1.) user klicks on an icon

    2.) the app impersonates the other AD account

    3.) There is a Win32 CreateFile call

    4.) Win32 API call for a copyfile

    5.) the file is closed (at the source)

    6.) impoersonation of the regular user's account

    7.)  firing up the associated application, mostly Word or Excel.

    The step number 3 usually takes 20-50 miliseconds on a test system.... and 30 seconds at customer side.

    And it occurs only in a Terminal Server environment...

    I know there are a couple of things going on before the createFile returns a handle, but for sure it is not the latency of the NAS system hosting the file share.

    We switched the impersonation off, logged on with the other AD account having access rights in the file share, and there was no special wait time  (<100 ms) during the CreateFile mentioned above. So it's not the file access latency of an overloaded NAS system.

    The process monitor doesn't show any interesting things during this "wait", the details of that CreateFile show me that there are 30 seconds spent, but they don't tell me for what.  We've put some debug output around the CreateFile and we see in DebugView that this API call hangs... and nothing before or after the CreateFile call.

    We also observed that one out of 10 times this 30 second wait doesn't happen...

    So how to investigate this further?

    Are there any security policy processing times when an app does an impersonation of another AD account and then accessing the file share? The customer sent to me a GPresult for the server, but most settings there restrict things on Remote Desktops like hinding the control panel, the task manager and other things.

    For sure this isn't the first impersonation in the application - after starting the app  it does an user access right check and to do that the first impersonation is called very early.

    The "hung" CreateFile call happens abut 10 minutes later...


    Thursday, August 6, 2015 3:44 PM


  • Andreas,

    Do you have experience using WinDbg?  I would suggest the following action in the debugger:

    • Make sure you have your symbol server settings to bring in the Microsoft public symbols from http://msdl.microsoft.com/download/symbols
    • Set a breakpoint on the code that makes the CreateFile call in step 3.
    • When the debugger breaks in, step into (F11) the CreateFile function call.  (Obviously, you don't have source, so you'll be in assembly code.)
    • Execute this command "wt -or -l9"

    That tells it to trace the execution until it returns, going up to 9 levels deep.  You will see a tremendous amount of "spew", probably, as it emits information about the calls being made.  At some point, you may be able to observe what it is doing/calling when the long pause occurs.  Or if the long wait is actually lots of code executing, you should see that too.  Maybe this will help narrow it down.


    Developer Support Engineer

    • Marked as answer by Shu 2017 Tuesday, August 18, 2015 2:54 AM
    Friday, August 7, 2015 12:35 AM