[cifs-protocol] [REG:110100100943069] appcrash during win764bit domain logon

[Bryan Burgin]

Günther,

Sebastian (copied) will follow-up with you on this issue.

Sebastian,

Ie4uinit crashing is just a symptom of  Günther's issue, but finding the root cause of the crash might illuminate what's going on.  When a new user is logged on for the first time, we run a number of setup applications to prepare the user's desktop.  Ie4uinit is one of those.  There is a long (~3-4 minute) delay when first logging on and while ie4uinit is experiencing an appcrash (access violation), other setup apps may be experiencing timeouts before exiting.  A log from wmsetup (Windows Media) captured at the same time suggests this.  It may involve the non-existence of a path for the new user.  The solution may involve identifying what is missing and for Samba to ensure that it is provided.  We can discuss this more.

As for the crash itself, it happens before the desktop is available, so it was difficult to snap a dump.  We recovered some information from the event log, but we didn't find the usual .hdmp dump, probably because it was supposedly written to the user directory that didn't exist.  I forsed (via the keyboard) a full memory dump, but that hasn't provided much information yet.  The module ie4uinit is loaded (per LM), but I don't see any cite of it as an executing process (per "!process 0 0") nor any thread with it on the stack (per "!stacks 2 ie4uinit!").  It doesn't help that the app is a 32-bit application running under WoW64 on this x64 Win7 build.  We were also able to bring up the Task Manager (via C-A-D) and force a dump of ie4uinit (via Process, find ie4uinit, right-click, select dump), but WoW64 may be obscuring the root cause.

One of the problems is that this only happens at first logon before he desktop becomes available.  On each test pass, we have to make a new user.  However, I looked at the code for ie4uinit and there are a number of command line arguments that we might be able to use after the first logon to trigger this at-will.

Further, Günther might be able to come up with a cookbook of how to trigger this in a pure Windows environment to make diagnosing this easier.  Also, I believe he is going to capture a network trace at the time of this event to see what traffic is involved at this time.

I'll pass on all the dumps we collected.

Bryan

-----Original Message-----
From: Bryan Burgin 
Sent: Friday, October 01, 2010 5:29 PM
To: Guenther Deschner (gd at samba.org)
Cc: MSSolve Case Email; 'cifs-protocol at samba.org'; 'pfif at tridgell.net'
Subject: [REG:110100100943069] appcrash during win764bit domain logon


Günther,

I created SR 110100100943069 to track this issue (described below).  I or someone from my team will follow-up with you

Bryan


this is the crash info which I can reproduce at will:

* create a samba3 domain controller
* have this smb.conf setting: "logon home = \\%N\%U" (which will cause every user to have '\\sambadc\username' as their homedirectory (not profiledirectory) in the samlogon reply
* if that share does not yet exist on the sambadc and samba returns NT_STATUS_BAD_NETWORK_NAME for the share connect, then during logon for the first time on a win764bit box (haven't tested others yet), then I see that crash happening

Once I pre-create that share and login, it all succeeds and there is no crash.

Thanks,
Guenther
-- 
Günther Deschner                    GPG-ID: 8EE11688
Red Hat                         gdeschner at redhat.com
Samba Team                              gd at samba.org
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: appcrash.txt
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20101003/02422908/attachment.txt>