Video Screencast Help

Black desktop on first logon when a layer is active (Windows 7 x86)

Created: 10 Sep 2010 • Updated: 10 Sep 2010 | 17 comments


We're having some strange problems when some layers are active and a new user logon for the first time in the computer. The user gets a black screen, no dekstop, no taskbar, nothing but the mouse cursor is showing up. The user can use CTRL+ALT+DEL to execute task manager, logoff, etc. If the layer is inactive, the user gets the usual blue windows 7 screen and all works properly. After this first successful logon, if the layer is active the desktop appears correctly so we suppose there is some problem with the profile creation when the layer are active. The user is a normal user, not administrator rights.

We have started to see this behaviour when exporting the layers to a machine that has been deployed using sysprep (with the copyprofile=true statement in the XML). The profile for a new user and its desktop is created right if the layer is deployed to a fresh windows 7 installation made by hand. So there is something related to the windows 7 OS made with sysprep.

We've created a simple layer made by the following files and the problem appear too:

C:\ProgramData\SimpleApp.ico == C:\Users\All Users\SimpleApp.ico

* The "App.lnk" is a link to "%ProgramFiles%\Internet Explorer\iexplore.exe"
* The icon is setup as %ALLUSERSPROFILE%\App.ico

These files are in the C:\fslrdr\22\[_B_]COMMONAPPDATA[_E_] and C:\fslrdr\22\[_B_]COMMONDESKTOP[_E_] folders. Our exclusions are only the global ones provided by our SWV version (6.2.1562). The workstation agent is installed without the GUI.

Any idea about what the problem is and what to try?

Thank you very much!

Comments 17 CommentsJump to latest comment

ManelR's picture

When the user is in the black screen and he does the CTRL+ALT+DEL, the screen changes to the blue one with different options: logoff, execute task manager, change user, etc.

If we choose execute task manager, we can see "explorer.exe" running at 50% all the time and the computer is slow. If we kill it, and run it again, the CPU increases to 50% or more and all is the same ... If we choose to show process from all users we can see that "consent.exe" is taking the rest of CPU 45-50% because this operation need to be executed from an administrator ... the dialog for entering an admin password doesn't appear and the PC is almost unusable.

The problem is something related to the profile creation with the layer active.

Any idea?

IT Systems Manager
LCFIB - Computing Lab
Barcelona School of Informatics
Universitat Politècnica de Catalunya - Barcelona Tech
ManelR's picture

We've used CTRL+ALT+DEL to change user and logon as administrator (the workstation is not in a domain and we can logon concurrently). In the administrator account we've executed Process Monitor, apply a filter for showing things for the 'hang user' and we see a lot of ACCESS DENIED for virtual registry keys for the explorer.exe process of the user.

If we use Process Explorer we can see the explorer.exe of the user at 50% and ... if we do a "svscmd layer D" for deactivating it ... we show the explorer.exe starting to execute some processes and finishing with a low CPU% use.

If we change again to the user session, the desktop is there ... so the profile creation has finished properly. After that, we can activate the layer again and the icons are in the desktop ...

We're very worried about this problem.

I hope someone has any solutions or tips about wha'ts happening ...

Thank you.

IT Systems Manager
LCFIB - Computing Lab
Barcelona School of Informatics
Universitat Politècnica de Catalunya - Barcelona Tech
Nirmal R's picture

Sorry that you are running into a problem. Please contact support or sales and provide the details. We'll create a ticket and take it from there.


ManelR's picture


I've just send an email message to our support contact. I hope he can solve or scale this problem as soon as possible.


IT Systems Manager
LCFIB - Computing Lab
Barcelona School of Informatics
Universitat Politècnica de Catalunya - Barcelona Tech
ManelR's picture


We've contacted and did some tests with support and we know that the problem is related to having MUICache with incorrect rights for the users in the read-only layer.

For example, having something like this:

[HKEY_USERS\USER_TEMPLATE\Software\Classes\Local Settings\MuiCache\7\A7EAB198]

will make the problem appear because this setting is copied to the user registry but the user doesn't have access to "MuiCache\7" nor "MuiCache\7\A7EAB198" (these two latests keys are random letters and numbers).

We're trying to know why some programs and actions in a layer captures these registry entries ...

I hope we have some clues in the future. By now we're looking at all our layers and deleting the latest key (A7EAB198 or something else). Then the user can logon without problems and create his own registry full of entries.

I'll post more info in the future ...

IT Systems Manager
LCFIB - Computing Lab
Barcelona School of Informatics
Universitat Politècnica de Catalunya - Barcelona Tech
Kirk Panitz's picture

I also experienced this issue, and have since removed it from all 50+ virtual applications we have in production.

The MUICahce problem that ManelR decribes is part of the problem. The overreaching problem is that you are capturing your layers with local administrator access and it seems that any files/registry entries that run under "USER_TEMPLATE" atempt to run with current user access.

What that means is that if you are leaving any entries in HKEY_USERS or USER_TEMPLATE you must ensure that limited users have access to atleast read & execute them.

ManelR's picture


Enterprise Support has filed a bug ticket in etrack and submitted to their engineering team. I don't know if this forum policies permit posting the etrack ID number so I'm not posting it at this moment.

See you.

IT Systems Manager
LCFIB - Computing Lab
Barcelona School of Informatics
Universitat Politècnica de Catalunya - Barcelona Tech
t.schulz's picture

there are already new insights about this problem? We have the same trouble!

Thanks in advance

JonyAM's picture

This problem occurs not only in login when the layers are actives on startup. If the layers are deactivated on startup, and after to logon we activate some of them, after a little bit of time, explorer.exe and the executable of the layer that have the problem increases your usage and machine turns inestable.

I can see with procmon same problem that describes ManelR, a lot of ACCESS DENIED for virtual registry keys but not only for the explorer.exe, for the process of the layer i'm executing too.

In my case, like said Kirk Panitz, we make the layers with administrator user, and activate them with an standard user (using runas for launch svsadmin.exe).

That's a big problem.

ManelR's picture


So, the question is, from where USER_TEMPLATE values are captured? How the capture logic fills this section?

Are these values a copy of the ones from the user that is doing the setup (normally an administrator)?

Or are these values a copy of files created for every user in the system by the installar?

I would like to know how this section is created so we can decide if values inside USER_TEMPLATE are always needed or we could clean them ... (actually I clean TEMP, CACHE, COOKIES, etc. but sometimes I don't know if we need to clean APPDATA, LOCALAPPDATA, etc.)


IT Systems Manager
LCFIB - Computing Lab
Barcelona School of Informatics
Universitat Politècnica de Catalunya - Barcelona Tech
ManelR's picture


We would like to know how the capture process determine wich information goes to USER_TEMPLATE sections ... Any idea?

I've did a test, I've captured an application. After that I've reviewed the file/registry and deleted all things below USER_TEMPLATE.

 But, when an user logon on the workstation I can see that some entries are added to the writable section of the user registry ... and surprise some of these registry entries that the user will need to read are protected. These keys didn't inherit the ACLs for the user. An example are:

Windows Registry Editor Version 5.00




@="URL:cai Protocol"
"URL Protocol"=""



@="\"[_B_]PROGRAMFILES[_E_]\\IBM\\Lotus\\Notes\\framework\\rcp\\rcplauncher.exe\" -config notes -maxargcnt 7 \"%1\""

[HKEY_USERS\S-1-5-21-2193039353-3591749179-3167676598-1147\Software\Classes\Local Settings]

[HKEY_USERS\S-1-5-21-2193039353-3591749179-3167676598-1147\Software\Classes\Local Settings\MuiCache]




Any idea about why these keys are created for the user below his registry key without access?


IT Systems Manager
LCFIB - Computing Lab
Barcelona School of Informatics
Universitat Politècnica de Catalunya - Barcelona Tech
Jordan's picture

User template stuff is created when anything is written to the currently log in user's (the one doing the capture) settings area in windows.

If a forum post solves your problem please flag is as the solution

Eaglatwo's picture

I've seen this problem in our environment of 32-bit Win7 with at least three apps of about 10 virtualized with SWV 6.1 SP4.

I now tried cleaning the .vsa packet of one problematic app from any MUIcache entries in the registry section, imported and activated it in a workstation and voi'la, no problems with user logins anymore when that swv-packet is in use.

Actually the packet with MUIcache entries caused 50 % (one processor core of the two going 100 %) explorer.exe processor use when I started the app after the activation so it seems (as noted earlier) that this is not only related to the logins.

Next I'll try the packet of Nokia's Ovi Suite in this manner... I only remove one registry entry from the packet (since user related stuff will be left out of the packet when exported):

Read-only / HKEY_LOCAL_MACHINE / SYSTEM / CurrentControlSet / Control / MUI / StringCacheSettings / StringCacheGeneration

I'll try with removing it from the point of MUI.

martin's picture

My goodness, how many hours have I spent and spoiled.

For the search engines:

I use SWV at home, with the goal to keep my Windows 7 installation clean and allow otherwise conflicting software to co-exist on one system, or to test freeware/shareware before I install it permanently. I prefer the setting "keep in layer" to avoid multiple copies of the same files.

My PC suffered from 100% CPU load in one, several or all cores of my CPU within the System process, specifically ntkrnlpa.exe+0x6de2e, i.e. ntkrnlpa.exe!ExpWorkerThread (with Process Explorer) when symbols are configured.

Usually, CPU load jumped to 100% in one core when I started an app or left the system idle for some time - I always had a Firefox layer active for example.

With Photoshop Elements 8, the symptom appeared right after I created the layer and tried to use it. With Firefox however, it slowly crept into my system.

For analysis, I installed XPERF, only to find that profiling caused the problem immediately but did not help with analysis.

As soon as a core was afflicted, only reboot would help. When all cores were afflicted, shutdown would not finish anymore four hours.

Of course, all driver updates and re-installing Windows did not cure the problem. Process Monitor showed lots of ACCESS DENIED registry keys.

Only yesterday, after felicitous search words brought me to this thread, I deactivated all active layers - and the problem was gone.

No I'll have to find those bad registry entries within the layers, and learn how to efficiently remove them from all the layers. Unfortunately, in contrast to the layer folders, the registry structures are not colored grey if they are empty, and I did not yet find a way to edit them outside the SWV Admin GUI, ...

SK's picture

Hello Martin,

Please try SWV 6.1 SP6 MP1 HF1 to see if this issue still exists or not.


Connect Etiquette: "Mark as Solution" those posts which resolve your problem, and give a thumbs up to useful comments, articles and downloads.

martin's picture

As a preliminary result, SWV 6.1 SP6 MP1 HF1 solves 'most of the issue'.

In detail: after the first massive appearance of the issue (summer 2010), I re-installed Windows 7 (-32 of course, on July 14), got confused with my downloaded SWV installers and accidentally installed SP1 MP1. I re-imported the VSA archives and only encountered the problems again from beginning of december 2010.

After Christmas, I uninstalled SWV and installed 6.1 MP1 HF1 because the installation guide says to do it that way.

Unfortunately I thought i read the guide right that all settings would remain that way. So I did not check the global excludes. But global excludes are now stored in a different format inside the registry, so the new version did not us the old setting.

Although I did not delete / re-import the layers, V6.1 accepted them gracefully, it seems. I think I encountered the 100% CPU issue once or twice with only one of my layers since, but far! less than before and I think the reason might be the old layer(s).

martin's picture


The issue still persists.

I observed 100% CPU load of all of my 4 cores while a layer was active, where I newly captured an Atmel AVR development toolchain, a commercial compiler, and eclipse. The attribute "keep changes in layer" is not active for this layer.

When the CPU load started, also a Firefox layer was active. But deactivating that layer did not reduce CPU load, but only deactivation of the last layer, in this case.

I can reactivate the layers right afterwards, and continue my work. Just all my edits and open webpages are gone.

Meanwhile, I know the symptoms quite well. I have Process Explorer showing CPU load permanently in the systray and it tells that "System" is the causing process. But the first indicator is the CPU fan - it often helps me to save my edits, while not yet all cores are "infected".