Can you explain why DirectoryInfo.GetFiles produces this IOException?

Question

I have a WinForms client-server app running on a Novell network that produces the following error when connecting to the lone Windows 2003 Server on the network:

TYPE: System.IO.IOException
MSG: Logon failure: unknown user name or bad password.

SOURCE: mscorlib
SITE: WinIOError

  at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
  at System.IO.Directory.InternalGetFileDirectoryNames(String path,
    String userPathOriginal, String searchPattern, Boolean includeFiles, 
    Boolean includeDirs, SearchOption searchOption)
  at System.IO.DirectoryInfo.GetFiles(String searchPattern, 
    SearchOption searchOption)
  at System.IO.DirectoryInfo.GetFiles(String searchPattern)
  at Ceoimage.Basecamp.DocumentServers.ClientAccessServer.SendQueuedFiles(
    Int32 queueId, Int32 userId, IDocQueueFile[] queueFiles)
  at Ceoimage.Basecamp.ScanDocuments.DataModule.CommitDocumentToQueue(
    QueuedDocumentModelWithCollections doc, IDocQueueFile[] files)

The customer's network admin manages the Windows Server connection by manually synchronizing the workstation username and password with a local user on the server. The odd thing about the error is that the user can write to the server both before and after the error, all without explicitly logging on.

Can you explain why the error occurs and offer a solution?

Answer 1

I have this same problem when trying to access the file system of a windows server in a different domain. The problem is that the user account that the program is running under does not have access to the remote server. Windows does extra work behind the scenes to make it look seamless when you use Windows Explorer because it guesses that your remote credentials will match your local credentials.

If you map a drive locally to the remote server, then use the locally mapped drive in your code, you shouldn't have the problem. If you can't map a drive, but you can hard code the credentials to use for the remote server, then you can use this code:

using System;
using System.ComponentModel;
using System.Runtime.InteropServices;
using System.Security.Principal;

namespace Company.Security
{
    public class ImpersonateUser : IDisposable
    {
     [DllImport("advapi32.dll", SetLastError=true)]
     private static extern bool LogonUser(string lpszUsername, string lpszDomain, string lpszPassword, int dwLogonType, int dwLogonProvider, out IntPtr phToken);

     [DllImport( "kernel32", SetLastError = true )]
     private static extern bool CloseHandle(IntPtr hObject);

     private IntPtr userHandle = IntPtr.Zero;
     private WindowsImpersonationContext impersonationContext;

     public ImpersonateUser( string user, string domain, string password )
     {
      if ( ! string.IsNullOrEmpty( user ) )
      {
       // Call LogonUser to get a token for the user
       bool loggedOn = LogonUser( user, domain, password,
        9 /*(int)LogonType.LOGON32_LOGON_NEW_CREDENTIALS*/,
        3 /*(int)LogonProvider.LOGON32_PROVIDER_WINNT50*/,
        out userHandle );
       if ( !loggedOn )
        throw new Win32Exception( Marshal.GetLastWin32Error() );

       // Begin impersonating the user
       impersonationContext = WindowsIdentity.Impersonate( userHandle );
      }
     }

     public void Dispose()
     {
      if ( userHandle != IntPtr.Zero )
       CloseHandle( userHandle );
      if ( impersonationContext != null )
       impersonationContext.Undo();
     }
    }
}

Then you can access the remote server by doing this:

using ( new ImpersonateUser( "UserID", "Domain", "Password" ) )
{
    // Any IO code within this block will be able to access the remote server.
}

Answer 2

I think you should try to reproduce the problem, and than use a packet monitor to see the network traffic and look at the difference between the failure situation and the success situation.

Then write a application which uses the raw api's from windows (P/Invokes) to reproduce your failure situation and try to find which parameters cause the error to occur. If your able to solve the problem than it's just the matter of finding how to get the components to do the thing you want.

Other directions you could look at (after you can stably reproduce the problem):

• Use Process Monitor to log all api calls and see where the error comes from.
• Try it on a clean VM/Machine and try to reproduce it there
• Disable the virus scanner
• Update the novell client

Answer 3

IMHO, it seems to be some kind of side effect of refreshing an expired authentication token (or something like that).

I my case, as an Active Directory user having internet access through a proxy (squid), I am browsing without problems until I get (at random intervals) an error about lack of credentials, which is solved by a page refresh in the browser, then everything is working fine until the next error.

Answer 4

amazing it worked like charm, saved my time, thanks

Answer 5

Exactly what I needed! And with absolutely no modifications, NONE! Thanks!