Günther, I'm going to continue to work with you on this. In parallel to the research I'm doing on this end, I wanted to know if we could switch the testing you're doing to Windows 7 x86 and capture me a fresh process dump as well as a netmon trace? The binary that is running in Windows 7 x64 is a 32-bit binary and is running under WoW64 (a Windows-on-Windows environment that allows x86 applications run on Windows x64). The dumps we produced captured the WoW64 address space, but not the ie4uinit.exe space.
When the error dialog is displayed, invoke the Task Manager via Ctl-Alt-Del, find the process i4euinit.exe and select (right-click) Create Dump. Also capture a netmon trace. You may be running into something related to [MS-GPFR] (below). As you work on that, I'm investigating how to repro this in your environment at times other that the first logon so we can capture more meaningful diagnostics. I'm looking into ie4uinit's command line arguments and registry entries to see how to cause it to repro while fully logged on (instead of only at the first logon while the desktop is "preparing"). I am also investigating reproing this in-house, but I would need your help to accomplish this. My office is right next to Nick's, so I may be able to leverage his assistance. Bryan Group Policy: Folder Redirection Protocol Extension, as specified in [MS-GPFR]. This protocol enables an administrator to relocate certain file system folders, called user profile folders, to different paths, such as a shared network location. 1.3.2 Folder Redirection Protocol Overview The Group Policy: Folder Redirection Protocol Extension enables an administrator to redirect the location of certain file system folders, called user profile folders, to different paths such as a shared network location. When the operating system or application requests access to these redirected folders, the operating system automatically redirects the access requests to the location on a network share specified by the administrator. By convention, an operating system or application may expect to read and store a user's data in a set of folders within the local file system. For example, the operating system may conventionally store image files for user "Sue" in a folder of the local file system called \Sue\Documents\My Pictures. The Group Policy: Folder Redirection Protocol Extension allows an administrator to change the location of Sue's My Pictures folder from its default local location to a UncPath such as \\CorpServer\Users\Sue\Documents, thereby making it available to Sue from any machine on the network. This also enables the administrator to manage its storage from a central location. The Folder Redirection Administrative-Side Plug-in provides a user interface by which network administrators can establish and update folder locations for users' folders. It relies on the Group Policy Protocol, as specified in [MS-GPOL], to specify the location of the remote storage location where the folder redirection configuration data should be stored. This GPO path is metadata in a GPO that is stored on the domain controller where the Folder Redirection Protocol configuration data is stored. The plug-in uses SMB operations, as specified in [MS-SMB], to retrieve existing configuration data (in the form of files) from that location and to store updated configuration to it. <1> Section 1.3.2: In Windows 2000 Server, Windows XP, and Windows Server 2003, a constant list of exactly five user profile folders can be redirected, including My Documents, My Pictures, Desktop, Start Menu, and Application Data. In Windows Vista, Windows Server 2008 Windows 7, and Windows Server 2008 R2, the set of folders that can be redirected is extensible and includes, by default, the additional folders Music, Videos, Favorites, Contacts, Downloads, Links, Saved Games, and Searches. The Group Policy: Folder Redirection Protocol Extension is not available on operating system versions earlier than Windows 2000 Server. -----Original Message----- From: Bryan Burgin Sent: Saturday, October 02, 2010 11:38 PM To: Guenther Deschner ([email protected]); Sebastian Canevari Cc: MSSolve Case Email; [email protected]; [email protected] Subject: RE: [REG:110100100943069] appcrash during win764bit domain logon 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 ([email protected]) Cc: MSSolve Case Email; '[email protected]'; '[email protected]' 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 [email protected] Samba Team [email protected] _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
