The Case of the Temporary Registry Profiles

re: The Case of the Temporary Registry Profiles

Matthew — Tue, 27 Apr 2010 10:34:45 GMT

Interesting artical and thanks for sharing!

re: The Case of the Temporary Registry Profiles

foxyshadis — Fri, 26 Feb 2010 01:37:26 GMT

@Karl

Sounds like you need to clean out your printer drivers and start reinstalling them until you find out which one is breaking logon.

@all

The vast majority of these problems are caused by third parties hooking the logon in various ways. Microsoft can only be faulted for giving them the ability to shoot themselves in the foot, but they're still to blame for actually wrecking your user experience; blaming Microsoft for lack of foresight on the first implementation of a feature is pointless. XP & 2003 are long since out of mainstream support. The point of this blog is to show how you would determine which third-party component is doing it, so you can either disable it or make an informed bug report the developer.

re: The Case of the Temporary Registry Profiles

Ian W. Rudge — Fri, 29 Jan 2010 10:32:16 GMT

This was written to provide a means of reassociating profiles which have become detached from their accounts:

http://iwrconsultancy.co.uk/software/reprofiler/reprofiler.htm

I'll admit that at this early stage of development there are still one or two scenarios which it can't handle. That said it does work well enough to get most users out of dissociated-profile trouble.

re: The Case of the Temporary Registry Profiles

Karl Kiniger — Mon, 18 Jan 2010 16:07:07 GMT

OK, just captured a similar race between spoolsv and winlogon on XP embedded.

This has been giving us major headaches alreay so I am glad I came over this thread to find the root cause. On our systems about 1 of 20 boots are failing because of this.

grrr..

Karl

re: The Case of the Temporary Registry Profiles

Kemp — Sat, 16 Jan 2010 17:24:06 GMT

Or did I read it wrong and it's the program in the new thread which waits 10 seconds? Still seems a bit of a kludge because on systems where the login has different timing, this could cause services provided by the app to be unavailable for a few seconds after login apears to have finished. Fine for a human who can't react that fast, but I wonder how long it'll take for a company to file a bug along the lines of "Our script which does X and Y after [or during] boot using operations enabled by your software no longer works on 30% of our computers."

re: The Case of the Temporary Registry Profiles

Kemp — Sat, 16 Jan 2010 15:24:43 GMT

I can't believe no one has mentioned this yet... Was the official solution (or workaround) to this problem in the new client really to just sit there delaying the user's boot for 10 seconds while nothing happens? As someone who was forced for several years to use a networked Windows system that had hideously slow logins (we're talking several minutes minimum and up to 10-15 minutes and sometimes more during peak times), I shudder to think that software may be deliberately delaying this to an even further extent.

re: The Case of the Temporary Registry Profiles

YUSPINO — Sat, 28 Nov 2009 23:53:27 GMT

Yes, yes. The google Updater is the cause. I have this problem with Windows 7. when uninstalling Google updater I could go to a "termporary profile" normally in real time.

Thanks.

Mark superhero.

re: The Case of the Temporary Registry Profiles

Erika — Thu, 12 Nov 2009 10:32:20 GMT

We encounterd a similiar problem with our Antivirus. The Realtime Scanner accesses all ntuser.dat when the computer starts. When the user logs on quickly, nothing is reported. When the user logs on after some time, there is a sharing violation from Rtvscan.exe on the users ntuser.dat.

When the user logs on exactly when Rtvscan access his ntuser.dat, the Temporary Registry Profile problem occurs.

I sent procmon.log to the MS Engineers, but in my opinion they where not able to interpret the log file...they should be more engineers like Mark understanding the Windows logon process...

re: The Case of the Temporary Registry Profiles

MattW — Wed, 04 Nov 2009 17:54:56 GMT

Several comments suggested a flaw in the file system regarding access sharing and file locks and targeted the Logical Prefetcher (LP) as the problem. However, these seem to miss the point, as the LP already utilizes read-only access and specifies full sharing. The problem in this case really lies with Winlogon because it requires exclusive access.

The article does identify a weakness of the LP in that 1) it cannot distinguish between simultaneous System processes that are non-related (such as the cached IO file operations) from those initiated by the launching process and 2) future LP activity can initiate unnecessary reads, specifically those from the previous unrelated System processes, which could cause collisions with Winlogon. The LP has been modified in Vista and Windows 7 to work around this issue as it pertains to the LP.

I wonder if the LP can be reengineered to only associate the simultaneous System processes that are actually initiated or indeed related to a launching process and also if Winlogon should be modified in a way to play more nicely? In the meantime, using the tools and debugging techniques outlined can help identify troublesome startup processes and a log-off script deleting the offending prefetch files can create a work around.

This is a very interesting and informative article, none the less.

re: The Case of the Temporary Registry Profiles

Andreas — Tue, 27 Oct 2009 10:09:32 GMT

I have this problem too at my computer at home. If my wife has been logged on to her account and I log on to mine this happens ~50% of the time.

ASFAIK we don't have any Citrix stuff installed so there's no fix for us. It's a bit weak by MS to not solve it properly themselves, since it's obviously a bug in how the cache manager interacts with the rest of the system at logon.

At least now I know how to find out what application the prefetcher will think was associated with the registry read so I could write a script tot delete those pf-files at logoff.