New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 46 users

Issue metadata

Status: Untriaged
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Regression

Sign in to add a comment

Running chrome causes 100% cpu usage of lsass.exe

Reported by, May 18 2014

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.137 Safari/537.36

Steps to reproduce the problem:
1. Load Chrome
2. View CPU details in Process Explorer for lsass.exe

What is the expected behavior?
The CPU usage of lsass.exe should be very low

What went wrong?
The CPU usage of lsass.exe is 100% of core for a minute + when starting chrome

Did this work before? N/A 

Chrome version: 34.0.1847.137  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 13.0 r0

There's a few posts around the net that this may be related to Chrome sync but that's currently unconfirmed.
Showing comments 16 - 115 of 115 Older

Comment 16 by Deleted ...@, Oct 20 2014

Also seen on Win 7 32bit, but only on one user profile. Is this malware ?
I'm seeing this problem on Win 7 32-bit.

Comment 18 by Deleted ...@, Nov 17 2014

Same problem on Win 7 64 bit

Chrome version:  41.0.2220.0 canary (64-bit)

Comment 19 by Deleted ...@, Nov 25 2014

Same problem with Chrome on Windows 7 64bit.
Allright it has been almost a year already. How can this bug still be unconfirmed?? I have this problem on my Thinkpad T420 with Intel Core i5-2540M with Win7 64bit and Google Chrome 39 which is 5 major versions since the big was reported! As usually Google ignores people it seems...

Comment 21 by Deleted ...@, Dec 25 2014

Same problem with Chrome on Windows 7 64bit
sametime chrome does not startup
no viruses at laptop
I resolved this on my machine.  Turns out it was a really hard to find virus/Trojan.  Tried many virus programs and the only one that found it was webroot. 
It is really annoying to have this issue. I uninstalled chrome and can't access my bookmarks now. I have a single core pc and lsass.exe just makes it unusable. Reinstalling Chrome doesn't solve the problem. After closing Chrome, one instance of Chrome.exe is still hanging and I have to kill it in order to unfreeze the system.

@comment #22: can you tell me more about webroot and how you did fix the problem?
Turns out this was a really obscure virus that none of my virus programs picked up, including Sophos Enterprise virus. I knew it was a virus because when opening Task manager, and then looking at resource monitor, I noticed 100's of network sockets being opened to obscure IP address. The virus program that finally found it was Webroot SecureAnywhere Antivirus. I did a 30-day trial and cleaned it up. Once the virus was gone, all of the lsass.exe CPU resources disappeared.
you have not provided any info about name of the virus, infected files/processes or anything. So this information is useless unfortunately. Could you please check the Webroot scan log or something and paste the result here? But I doubt everybody here has a virus causing this lsass several minutes cpu overload...
Interestingly enough my Win8.1 machine with Chrome does not suffer from this behavior. Lsass.exe is completely calm there with Chrome
I fixed this about 3 months ago and don't have the logs,  sorry.  I was just trying to help,  so apologize for the info being useless.  Good luck. 

Comment 27 by Deleted ...@, Jan 2 2015

I am working on this issue right now.

Using some clues from you all here, I've tracked it down this.

Process explorer shows a security token request and termination loop happening under lsass.exe, with token being <LaptopName>\<account>:1c42f

Such as: Smith_VAIO\John:1c42f

Upon inspection with Process Monitor, we see the following:

11:34:57.3492434 AM	lsass.exe	908	RegQueryKey	HKLM	SUCCESS	Query: HandleTags, HandleTags: 0x0
11:34:57.3492833 AM	lsass.exe	908	RegOpenKey	HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-21-563832473-1690269938-841482641-1000	SUCCESS	Desired Access: Read
11:34:57.3493295 AM	lsass.exe	908	RegQueryValue	HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-21-563832473-1690269938-841482641-1000\ProfileImagePath	SUCCESS	Type: REG_EXPAND_SZ, Length: 28, Data: C:\Users\John
11:34:57.3493613 AM	lsass.exe	908	RegQueryValue	HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-21-563832473-1690269938-841482641-1000\ProfileImagePath	SUCCESS	Type: REG_EXPAND_SZ, Length: 28, Data: C:\Users\John
11:34:57.3493926 AM	lsass.exe	908	RegCloseKey	HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-21-563832473-1690269938-841482641-1000	SUCCESS	
11:34:57.3495197 AM	lsass.exe	908	CreateFile	C:\Users\John\AppData\Roaming\Microsoft\Protect\S-1-5-21-563832473-1690269938-841482641-513\Preferred	PATH NOT FOUND	Desired Access: Generic Read, Disposition: Open, Options: Sequential Access, Synchronous IO Non-Alert, Non-Directory File, Attributes: HS, ShareMode: Read, AllocationSize: n/a, Impersonating: Smith_VAIO\John

This behavior loops.

Sometimes throwing in:

11:34:57.1073869 AM	lsass.exe	908	CreateFile	C:\Users\John\AppData\Roaming\Microsoft\Protect\CREDHIST	SUCCESS	Desired Access: Generic Read/Write, Disposition: OpenIf, Options: Synchronous IO Non-Alert, Non-Directory File, Random Access, Attributes: HS, ShareMode: None, AllocationSize: 0, Impersonating: Smith_VAIO\John, OpenResult: Opened
11:34:57.1074461 AM	lsass.exe	908	QueryStandardInformationFile	C:\Users\John\AppData\Roaming\Microsoft\Protect\CREDHIST	SUCCESS	AllocationSize: 24, EndOfFile: 24, NumberOfLinks: 1, DeletePending: False, Directory: False
11:34:57.1074769 AM	lsass.exe	908	CreateFileMapping	C:\Users\John\AppData\Roaming\Microsoft\Protect\CREDHIST	FILE LOCKED WITH WRITERS	SyncType: SyncTypeCreateSection, PageProtection: 
11:34:57.1075034 AM	lsass.exe	908	QueryStandardInformationFile	C:\Users\John\AppData\Roaming\Microsoft\Protect\CREDHIST	SUCCESS	AllocationSize: 24, EndOfFile: 24, NumberOfLinks: 1, DeletePending: False, Directory: False
11:34:57.1075669 AM	lsass.exe	908	CreateFileMapping	C:\Users\John\AppData\Roaming\Microsoft\Protect\CREDHIST	SUCCESS	SyncType: SyncTypeOther
11:34:57.1076805 AM	lsass.exe	908	CloseFile	C:\Users\John\AppData\Roaming\Microsoft\Protect\CREDHIST	SUCCESS	

So...Using that info, I went to the path "C:\Users\John\Appdata\Roaming\Microsoft\Protect\" and found one folder with a random guid that was created days ago.  lsass.exe was currently still in a 'stuck' state, when I deleted this guid folder, and another one was immediately created with a new guid.  The next step is probably unnecessary, but I deleted the newly created guid folder as well, and this time it did not respawn.  lsass.exe processor time was back to normal.  I attempted to close chrome, at which point it closed properly.  I reopened chrome, observed lsass use some cpu for about 10 seconds, then stop.  I closed chrome, and the process terminated properly yet again.  I then reopened chrome to observe the same behavior as previous (normal behavior).

So, conclusion, the folder located at "C:\Users\<username>\appdata\roaming\microsoft\protect\<guid>" must be deleted.

That worked in my case.

Hope you value the info!

Comment 28 by Deleted ...@, Jan 3 2015

had same problem for about 5 months, lass.exe would consume 25% of CPU (it would either hit one of 4 cores to 100% or spread the load across multiple cores.
Monitoring system for multiple days indicates that lass.exe keeps CPU busy more than 1% of total time system runs, which is way too high compared to other processes. 
I deleted folder as per "jd.." post, it seems to work for now. 

6.5 KB View Download

Comment 29 by Deleted ...@, Jan 11 2015

Each time when chrome is started lass.exe will utilize cpu for just under a sec CPU to 100%, barely noticeable. 
I confirm issue is fixed after deleting the folder 

Note: if you have multiple local accounts, it needs to be done under every account.

Comment 30 by Deleted ...@, Jan 12 2015

Issue has not reappeared for my user, thankfully.

Comment 31 by Deleted ...@, Jan 13 2015

This has been occurring recently on my machine where the cpu usage of explorer.exe spikes after opening Google Chrome. The cpu usage of explorer.exe remains near 100 even after I close Chrome. After uninstalling, the issue did not seem to reappear. Problem is that I can't seem to reinstall. I will scan with Mbam to see what I could find.

Comment 32 by Deleted ...@, Jan 21 2015

To the guy who posted Comment #27 you're awesome bud, I can confirm that it worked for me and cleared up my lsass problems on Win7 Ultimate x86 with Chrome 39.0.2171.99 m

Comment 33 Deleted

Comment 34 by Deleted ...@, Mar 4 2015

Can someone here explain this fix to me? I'm finding a ton of directories and files in C:\Users\<username>\appdata\roaming\microsoft\protect\ and I don't want to just guess at which one is supposed to be deleted. Is there any theory behind this, or are you going by a timestamp, or basically, how do you tell which one to delete? Thank you!

Comment 35 by Deleted ...@, Mar 4 2015

Actually, nevermind. Being a cautious soul I decided to just zip the most recent guid and then delete the unzipped version. I restarted Chrome and all is well--yay! Thank you all!

Comment 36 Deleted

I don't expect my situation to generate a lot of interest, but XP exhibits similar behaviour by chrome/lsass.  Needless to say, on a single-core system the slowdown is far worse and lasts far longer.  Strangely, desktop updates [when Chrome closes, for example] are still horrendously slow even an hour after CPU usage returns to zero [or thereabouts].

For a while I suspected that Avast! realtime scanning was a factor but disabling that [and related features] had no beneficial effect.

FWIW:  I couldn't find the "magic" folder anywhere in the filesystem.
Confirming the issue on WinXP + Chrome 43.0.2357.124 m
Removing the user directory with GUID for ALL users on the system unfortunately DIDN'T help

Comment 39 Deleted

Comment 40 Deleted

Comment 41 Deleted

Comment 42 Deleted

Comment 43 Deleted

Comment 44 Deleted

Comment 45 by, Jul 9 2015

   Created a new rule in the Firewall settings to block GoogleUpdate.exe file and the problem disappeared under Windows XP SP3 indicating that the culprit in 100 % CPU usage was the activation of the security function of lsass.exe - regardless of its version under various MS Windows - by GoogleUpdate.exe rather than a specific bug.
   100 % CPU usage can be also reduced by increasing computer's RAM (memory) to 4 GB (better to replace than to add) and setting the following in Windows' System Properties->Advanced->Performance Options: (a) Visual Effects to Adjust to best performance; (b) in Advanced: Processor scheduling to Programs; Memory usage to System cache; and in Virtual Memory->Change->Custom size->4096 MB in Initial size and Maximum size (150 % of the physical RAM size, as shown in System Properties->General, would be better, but more than 4 GB on one drive is not allowed under Windows XP);  with more than 1 hard drive in the computer, it is better to set up virtual memory Initial/Maximum size to: Drive C: 2/50 MB and Drive [2nd]: 4096/4096, as described on
   Also, I disabled Automatic Updates in: Start->Control Panel->Administrative Tools->Services->Automatic Updates->double click->Startup type: Disabled & Service status: Stop(ped)->OK (, and fixed IE8 (IE7) of SP3 as advised by Microsoft on (SP2 on

Comment 46 by, Aug 4 2015

   I also uninstalled: Microsoft Office Live, Windows Live Upload Tool, Windows Live Sigh-in Assistant (affected Windows Live Mail, which affected Chrome), permanently overclocked video card by 35 % using the NVFlash utility (,1916.html) and single-core Pentium M CPU by 10 % in BIOS, optimized BIOS, (, especially manually configured DRAM Timing by SPD [Disabled] to 2; 3; 3; and 6 based on the readings from the CPU-Z utility (, and manually updated Chrome to 44.0.2403.125 m (by clicking on the "Customize and control" button in the upper right corner->About Google Chrome), as automatic update is disabled.
   Now, not only Chrome is snappy again, but also the computer is snappier.

Comment 47 by Deleted ...@, Aug 9 2015

I have the same issue on vista with latest chrome - re-install did not fix problem, have to abandon chrome at this  time

Comment 48 Deleted

Comment 49 Deleted

Comment 50 Deleted

Comment 51 by, Aug 9 2015

   wrjone, 1st, clean up Chrom by disabling plug-ins and extensions, especially Google Update, (
   2nd, I believe memory leakage contributes to the problem.  Check, if it persists just after turning Vista up while with turned down anti-virus software, especially any on-line (v. bad) whereas K------ky ($5 online for 1-3 desktop licences) allows for manual customization (others don't).
   3rd, uninstall ( all bloatware ( and unnecessary freeware ( by removing (Start->Control Panel->Add or Remove Programs).
   4th, disable any software you do not need at the computer's start (Start->All Programs->Accessories->System Tools->System Configuration Utility->Startup-) by unchecking each after googling its purpose).
   5th, disable or set to manual (Start->Control Panel->Administrative Tools->(Component Services)->Services (Local)->Standard) not needed services in Windows XP ( or Vista (
   Also, I turned off: in Chrome - the phishing and malware protection; in the K------ky anti-virus software (others disallow) - the anti-spam and anti-banner functions, but not the mail anti-virus, web anti-virus, or firewall, which (all 3) are essential to stay safe (in adition to slowing down computer or network: the file anti-virus, if you download unknown files; the network attack blocker, if you use Wi-Fi/wireless network; the IM anti-virus, if you use IM; the application control, if you allow to-/install free software that is a bad idea, etc.).

Comment 52 by, Aug 10 2015

   & one more possible culprit: driver for Realtek chip sound card incl. the soundman.exe file (Start->All Programs->Accessories->System Tools->System Configuration Utility->Startup).

Comment 53 by Deleted ...@, Sep 10 2015

i cleaned visits history and glad

Comment 54 by, Sep 25 2015

To #27, can confirm, had the same problem on my Win 7 x64 Chrome  45.0.2454.101

Your solution worked, fantastic work. Many thanks.

Comment 55 by, Oct 23 2015

After reinstalling/updating Windows XP SP3, the 46.0.2454 version of Chrome became much faster.  Chrome's automatic update is disabled, so a new version will not override the original Windows setup.  K------ky anti-virus software is set up to a minimum of functions.  The 'Use hardware acceleration when available' option is working and does not slow down Chrome anymore.  Finally, a success with Chrome on Windows XP.
Verified the issue on Latest Stable# 47.0.2526.80 and Latest Canary# 49.0.2586.0 on Windows and could not reproduce the issue.
@steven+old -- Could you please re-check on Latest versions mentioned and update the issue.
Thanks in Advance.

Comment 58 by Deleted ...@, Dec 19 2015

See the same thing on Win7Pro 64

Comment 59 by Deleted ...@, Dec 19 2015

Just in case: Here is and I have seen this on the system every time Chrome starts.
So, I have tried various things:
- Updated windows
- deleted the history to the end of time
- rebooted
- uninstalled Chrome,
- rebooted
- installed Chrome
- rebooted
- ..
But no matter what I do, as soon as I start chrome, one core of the CPU gets pegged at 100% by lsass.exe. When quitting Chrome, the root process (which does not have a window) remains active(?!?) and lsass.exe continues too use 100% cpu time. When using the process explorer to kill that process as well lsass.exe goes back to 0% CPU usage.

So what ever Chrome is doing, lsass.exe pegs one CPU on a Win7x64 system (seen with latest public M47 build). 

Comment 61 by, Jan 20 2016

upon reading comment #27 on
I have confirmed temporary resolution is to backup and then delete sub folders inside folder located at "C:\Users\<username>\appdata\roaming\microsoft\protect\". For several times until lsass stops utilizing cpu.

also confirmed related (closed/not fixed) issue :

Later went on web and searched this specific path and found following article:
Titled: "How Private Keys Are Stored"
And is in set of articles about EFS...

So some part of security/encryption inside our browsers are starting this chain loop of errors. Probably because of bad implementation in WebKit crypt API. Why I say WebKit? It's because I'we located this problem on Opera 34 ("Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36 OPR/34.0.2036.47"). And what Chrome and Opera share? is WebKit of course. I haven't encountered this problem with any other software on my Windows 7.

Does not necessary relate that malicious plugins/addons are out of this scope.
I have 10 addons so I will investigate this later, if problem reappears.

TIP: Use start > run : "shell:DpAPIKeys" to open "protect" folder.

Project Member

Comment 62 by, Mar 10 2016

Labels: -Needs-Feedback Needs-Review
Status: Assigned (was: Unconfirmed)
Thank you for providing more feedback. Assigning to requester "" for another review.

For more details visit - Your friendly Sheriffbot

Comment 63 Deleted

Comment 64 by, Apr 3 2016

To comment #27 on
In Windows XP: C:\Documents and Settings\<username>\Application Data\Microsoft\Protect\<folder GUID>; globally unique identifier (GUID), e.g. "S-1-5-21-1715567821-1004336348-839522115-1003"

Comment 65 by, Apr 4 2016

Also, by the nature of "lsass.exe" as the Local Security Authentication Server, maybe, it can be affected by a hacked router requiring blocking port 53 incoming only ( to prevent it being used for forwarding denial-of-service (Dos) attacks (  A network security guy from my IP Cablevision Optimum claimed that it is so, but I did nothing until, on April 4, '16, the cable Internet connection speed dropped to 10 kbps causing Chrome to crawl causing computer to crawl incl. an increased activity of the antivirus.  Instead of fixing my 100-Mbps Netgear RT314 Router, I replaced it with a 1-Gbps D-Link DGS-1005G Switch, and the connection returned to over 5 Mbps, Chrome regained its snappy speed and stopped hampering everything else incl. appearances of lsass.exe.  I do not know, if the drastic drop in the connection speed was caused by the hacked router, which I doubt, because its functionality was not compromised, or, rather by a restriction/screening placed on my connection by my IP Cablevision Optimum that was automatically removed once the new switch had been detected.

Comment 66 by, Apr 29 2016

Also, by the nature of "lsass.exe" as the Local Security Authentication Server, maybe, it could be invoked (called for) by (the part of) Chrome/extension (e.g. LastPass) storing the passwords or even the part of the antivirus that protects against unauthorized use of passwords, such as Safe Money of Internet Security, etc.? If a temporary disabling such a feature reduced the duration of 100 % CPU usage by lsass.exe, it must be it.

Comment 67 by, May 2 2016

To comment #27 on
If you delete the <folder GUID> (globally unique identifier) then you will lose all the Windows incl. Chrome stored passwords unless they are also stored in the free LastPass extension, etc.
Fix from "Comment 27 by Deleted ...@, Jan 2, 2015"

with deleting directory helped me also.
I confirm deleting "C:\Users\<username>\appdata\roaming\microsoft\protect\<guid>" solved it for me.

My issue was that as soon as I open Chrome, lsaas.exe jumps to 50% usage and stays constant. Only way to end the 50% usage was closing Chrome and then finding the last Chrome instance in Task Explorer, upon killing it, the usage drops to 0% instantly.
I can also confirm the solution in Comment 27 - deleting "C:\Users\<username>\appdata\roaming\microsoft\protect\<guid>" directories. In my case there were 2 directories to delete, both of which appeared empty. A new one was created upon opening Chrome again.

Running 53.0.2785.116 m on Win 7 Pro SP1

Comment 71 by, Oct 25 2016

I had same issue after deleting password for user in windows.
Setting password back solves the problem.
I did not know why :)
Comment 70 - as suggested Comment 27's fix worked, by deleting the Empty SID folder under %appdata%\Microsoft\Protect\

Thank you all for your input and the fix.  This was happening on Windows 7 Start 32bit using Chrome version 55.
Remedy in comment 27 fixed my similar problem. CPU: Intel Core i7-3537U, RAM: 8.0 GB, Windows 7 64-bit, Google Chrome Version 54.0.2840.99 m (64-bit).

Comment 74 Deleted

Solution provided in comment #27 does not working for me. as soon as i delete "C:\Users\<username>\appdata\roaming\microsoft\protect\<guid>" directory, it recreate the same with in 20 seconds. i tried deleting the directory more than 10 times and every time it reappear within 20 seconds.

I am seeing this issue for past 3 month. I am using Version 55.0.2883.87 on window 7.

Labels: Hotlist-Recharge-BouncingOwner
Owner: ----
Status: Untriaged (was: Assigned)
This owner is not able to receive e-mails, please re-triage.
To the guy who posted Comment #27 , a big thank you from here as well!

Comment 78 Deleted

Comment 79 Deleted

Comment 80 Deleted

Comment 81 Deleted

Comment 82 Deleted

Comment 83 by, Mar 8 2017

I had same issue and solved by Comments #27.
Labels: -Needs-Review
Cleaning up sheriffbot label "Needs-Review" label as a part of modified "Needs-Feedback" sheriffbot rule. [ref bug for cleanup 684919]
Do not follow Comments #27, it corrupted my user profile.
This happens after I change windows login password
Clearing chrome history (everything) works for me. 
I guess there is a bug in chrome that use new password to decode content encrypted with old password.

Comment 86 Deleted

I followed the comment #27 although I did not notice the lsass.exe.  This is a Windows 10 Professional computer with chrome version 64.0.3282.140 installed.  The reason I followed comment #27 because my IT personnel pointed out the issue due to my websites for work not loading. After deleting the GUID named folder under C:\Users\george******\AppData\Roaming\Microsoft\Protect\S-1-5-21-2846089578-343788219-4208666476-3232  The problem of the pages not loading cleared and was able to get back to work. The problem I ran into after that is now I can not save any passwords.  Settings are all correct but nothing will save even when it asks and I say to save and do not ask me again on this browser.  I have uninstalled chrome, re-installed chrome (no reboot in between) deleted user profile and resigned in to create new profile.  Nothing I have tried including deleting all history has worked.  Sure would like to know how to get things fully back to normal.
I confirm issue is fixed after deleting the folder 

Nailed it for me.  (comment # 27 and #29)

black and white.  Done!
I resolved the issue by running this

Although it threw up an error when installing, I ran it to the end and the problem was fixed
I confirm issue is fixed after deleting the folder 

(comment #88, #27 and #29)

I am facing this issue on Multiple workstations. All of which are Windows 8.1 Pro running Version 64.0.3282.167 x64 Chrome

I have deleted the folder as prescribed in comment #27, and while other users have reported this resolved their problem, the folder just returns after a few minutes and lsass.exe starts chewing up CPU again. 

Order of events.  
Access system suffering this issue.  Run Chrome, navigate to a page or two.  Observe lsass go crazy. Delete the GUID folder in AppData\Roaming\Microsoft\Protect, lsass starts to calm a little bit, the folder reappears and within minutes my PCU is bogged down by lsass. 

I've repeated these steps multiple times on the same system with the same user (non-admin user) and even deleted the folder, closed chrome, observed stable CPU (lsass under 1% utilization) and upon launching Chrome again the folder returns and lsass again eats up over 50% CPU. 

So at least for me, deleting that folder has not resolved my problem.

I've run some additional testing between Domain user accounts and a local user account and the local administrative account. 

This issue is observed under the following conditions:
•	Standard Domain User logged in, runs Chrome
•	Standard Domain User logged in, run Chrome with Admin rights (authenticated with domain credentials that have Administrative rights on the local system)
•	Domain User with local admin rights runs Chrome
•	Domain User with local admin rights runs Chrome run with Admin rights

The issue is not observed when:
•	Logged in as local user Administrator
•	Logged in a any Domain User, run Chrome with Admin rights (authenticated with local Admin credentials)
•	Logged in as a local standard user

So it seems, at least in my experience, to be linked to Domain user accounts and not local accounts. 

If you are in a environment were you have your files encrypted.  I suggest you don't delete that folder

( "C:\Users\<username>\appdata\roaming\microsoft\protect\<guid>").

In our environment at least the encrypted data became unable to be decrypted. I don't know if there is a way to fix that part of the issue but that is a much bigger headache.
"So it seems, at least in my experience, to be linked to Domain user accounts and not local accounts."

--> Aha, finally a step closer! None of the other suggestions/information worked for me.

My suggestion also:
*** DO NOT *** delete anything in the "protect" folder, as you'll most likely lose all your stored credentials (e.g. encryption, Google Account/Sync/History/...). This happened for me at least. And didn't solve the problem. Neither did clearing/cleaning up stuff.

Why doesn't the Chromium team do some efforts to solve this? Are we the exceptions?
I experience the bug in local standard user (non-admin, non-domain) account on Win7 x64 after changing user's password from local admin's account.

I think this is relevant --

It seams that actual problem when user changes password.
I have changed password at the time when problem presented it self first time.
So seams that Second part doesn't work very well restoring original master key. 
Or I have changed it more than once, since there wouldn't entire history of all passwords I have used. Guess this would be easy to test:
- change password
- reboot
- change password
- reboot
- start Chrome or any other browser that uses Chromium engine and monitor lsass process.

taken from :

"The user's master key is encrypted twice, and each instance of encryption is stored in one of two parts of the Protect file. The first part, the password encryption key, is produced by the Hash-Based Message Authentication Code (HMAC) and SHA1 message digest function and is a hash of:

- A symmetric encryption of the user's master key produced by 160-bit RC4.
- The user's security identifier (SID).
- The user's logon password.

The second part is the backup/restore form of the master key. This is needed if the user's password is changed on one computer but the keys are in the user profile on another computer, or if the administrator resets the user's password. In either case, the Protected Storage service, which cannot detect password changes to update Part 1, uses Part 2 to recover the master key and regenerate Part 1."


I've stumbled on this with one of my company computers. (I'm not working for Google.) I've noticed the following:

- The browser window cannot go to any web page before lsass finish execution. Appears that something in Chrome if firing lsass.
- lsass pegs the CPU for about 30-60 secs.
- However, if I open an incognito window (by pressing Ctrl+Shift+N), the incognito window can be used to browser web pages immediately. So apparently the issue is related to one of the profile services.

@msrchandra: Do you have any idea what/how is lsass used by Chrome? Since this is blocking web page loading, I guess we should also switch this to P1. But I'll let you decide.
My boss's computer is experiencing similar issues to what Comment 97 describes. Incognito mode works. Lsass.exe blocks chrome pages from loading the first time for about a minute or two and then is fine after that point. 

It is a domain joined PC, I have tried the other suggestions of renaming the folder in local appdata. No change. 

His ID is a standard domain user. No local admin.

Running the process as admin changes nothing.
Same issue as 97 & 98
I can confirm the issue described in many comments above.
Chrome version: 65.0.3325.162 64-bit
Windows 10 Enterprise 1607 OS build 14393.2068
Multi-domain enterprise environment.

After starting Chrome, I was *unable to load any page* in standard mode (incognito mode worked and I could open web pages). LSASS consumed 25% of CPU (basically one core). 

Process Monitor showed a lot (100s of thousands) of IRP_MJ_CREATE operations on non-existent paths %APPDATA%\Microsoft\Protect\{some SIDs}\Preferred (that resulted in PATH_NOT_FOUND)

The SIDs that were being tried were different than the existing directory in that path.

This situation lasted in my case for 9 minutes (with Process Monitor tracing on). Finally, it seems that one of the IRP_MJ_CREATE attempts hit the existing SID directory and this caused LSASS to stop consuming so much CPU and unblocked Chrome. Since then all accesses to path %APPDATA%\Microsoft\Protect\{SID}\Preferred use the existing {SID} directory name and are successful.

krystian: are the non-existent paths referring to an existing SID in your computer? (Execute "wmic useraccount get name, sid" to get the list.)
Microsoft Windows 10 Enterprise Version	10.0.14393 Build 14393
Chrome Version 65.0.3325.181 (Official Build) (64-bit)
Connected to domain enterprise environment.

Same observations as in 97-100

I see the pattern with ProcMon- creating:
C:\Users\[myuser]\AppData\Roaming\Microsoft\Protect\[differend SID]\Preffered

Additionaly, in each loop I see also:
RegOpenKey HKLM\System\CurrentControlSet\Control\StateSeparation\Policy

Tried to invoke "wmic useraccount get name, sid" as pointed in #100, but didn't get any results in 1 hour (run with administrator credentials; see only blinking cursor).

May all those SIDs seen by ProcMon somehow been pulled from AD of my company?

@lwchkg: no, in my case "wmic useraccount get name,sid" (after a very long wait) returns only a couple of SIDs for local accounts.

I investigated it a bit further and here are my observations:
1/ I captured another trace of file activity with ProcessMonitor. There were ~500k attempts to open SID-named files in path %APPDATA%\Microsoft\Protect\

2/ There is a lot of repetitions, same SID directories appear in the trace a couple of thousands times

3/ When I sorted and deduplicated directory names and extracted SIDs from them it turned out that they match the list of SIDs for AD groups the current user is a member of (i.e. the output of cmdline: whoami /groups).

Perhaps that's why it's difficult to reproduce this bug: it probably needs at least a setup with a user in a domain and many groups the user belongs to.

Comment 104 Deleted

I have found captured keys in registry:
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\GroupMembership
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\GroupMembership

Seems that lsass iterates over them again and again
Blocking registry entries (changing "count" value to 0 or renaming whole key) didn't help

I've found another suspicious thing.
One of first entries in procmon done by lsass is unsuccessful try to create an object (GUID) in "protect" directory:
"3:39:50.6644324 PM","lsass.exe","936","CreateFile","C:\Users\[username]\AppData\Roaming\Microsoft\Protect\[my SID]\8797b266-b845-46a3-8da4-d820ea4b78ed","NAME NOT FOUND","Desired Access: Generic Read, Disposition: Open, Options: Write Through, Sequential Access, Synchronous IO Non-Alert, Non-Directory File, Attributes: HS, ShareMode: Read, AllocationSize: n/a, Impersonating: [my domain user]"

I cannot find the GUID anywhere. It changes between consecutive Chrome runs, but in a single session an attempt to create the same GUID file is repeated few times.
+anthonyvd (owner of c/b/profiles)

anthonyvd: I'm passing this to you because msrchandra@ was offline for a long time. Please help me to pass the bug to the right people.

Anyway, with the info in #97-105, it looks like a bug in Windows rather than a bug in Chromium.

Some extra info for #97 (my colleague's computer) though, that it is not connected to a domain, has a fairly simple config (AFAIK no special group policy), and has no extensions other than those comes with Chrome. I'll get Process Monitor running when I get an opportunity to troubleshoot that computer again.

Re #101 and #103: I wonder what will happen if you use Process Monitor to monitor "wmic useraccount get name, sid". Looks like that operation triggers possibly the same bug.
I work at an MSP.  I've encountered this bug five times in the last two months, and renaming this folder always seems to resolve it: C:\Users\<username>\AppData\Roaming\Microsoft\Protect\ (and then a folder named similar to S-1-5-21-123122605-2216940694-3386457312-13130)
Deleting contents of C:\Users\<username>\AppData\Roaming\Microsoft\Protect\ did not solve this problem for me.
Deleting contents of C:\Users\<username>\AppData\Local\Google\Chrome\ did, however, solve this problem for me.
Is there a bugfix planned for this issue? I've been able to consistently reproduce the issue by changing the user password. It's obviously not ideal for users' chrome to slow down each time they change their passwords. Deleting the Protect folder (or DPAPI protected files in the Chrome profile) is not a viable solution.
Still as issue in windows 10.1803, resolved by the deleting the `<username>\AppData\Roaming\Microsoft\Protect\` solves it.
This is an issue on windows 10 LTSB 2015 10.0.10240, and updated chrome 67.0.3396. 

Deleting the Protect folder along with the entire AppData\Local\Google folder does not correct this issue. It is affecting a handful of my users, and one it reoccurred after rebuild.
I have no idea how to track this bug down as I do not know this code at all. I am removing my name fro this bug so it gets properly triaged.

Justin: This looks like a Windows-only bug. Could someone from the Windows team take on?
Update: While we have the symptoms of LSASS.exe going nuts and looping, it has similar symptoms (just slower) using IE. Considering its the lsass process, I believe it is something related to WIA/SSO/ADFS somehow. 

Firefox does not cause this issue. I believe this "new" issue was introduced in 50, as that was the first release that default behavior was to use WIA.
Showing comments 16 - 115 of 115 Older

Sign in to add a comment