locked
Black Screen after login - takes over a minute to login RRS feed

  • Question

  • HI,

    we are using Citrix Profile Management and FSLogix for Office containers.  It appears that after enabling FSLogix, the login times to servers (2016) have doubled.  Looking at the logon process , the SHELL portion takes about 25 seconds itself (I;m assuming this is the portion where the screen is black after logging in).

    From what I understand, the impact to login times should be minimal.  Any suggestions on where else I can look? I've looked through the event logs, fslogix logs, citrix profile mgmt logs, and looked at all my GPOs

    I havent found anything to identify what is causing the login process, actually the desktop loading process, to "hang" like it is.

    Thanks

    Friday, August 23, 2019 7:16 PM

All replies

  • Hi BadWold5150

    We've been experiencing the exact same issue, which I believe is related to the Windows Search Service.  I would be interested to here what Microsoft/FSlogix have to say about this issue?  I'm not whether this is CPU related, or just Search becoming corrupted.

    From the event logs it's the Search service that is timing out, rebuilding etc. and that the StartShell is kicking in.  Eventually if you log out enough users it sorts itself out.

    Thanks

    Wednesday, August 28, 2019 9:38 AM
  • Some information about your FSLogix configuration would be helpful. You are correct that the black screen portion is when shell/explorer is in the process of starting. This is also the time period where the Office containers for FSLogix are initialized. Container vhds are formatted here, which can take a little longer on the first login.

    Try switching between CCDLocations and VHDLocations - VHDLocations is usually more performant because it's writing directly to the VHD without caching or writing to multiple locations. You can also try putting your VHD temporarily on your local disk instead of network just to measure how much impact that is having.

    Wednesday, August 28, 2019 5:14 PM
  • Hello BadWolf5150 and HadlyMick,

    I'm sorry to hear that both of you are having delays logging into FSLogix. This is an issue that you will probably need to open an FSLogix Support Request to resolve since you will need to send machine specific information to support to troubleshoot your issue.

    If you are able to successfully login after a delay, you will probably just need to send the results of the FSLogix support tool to support.

    If you are experiencing a hard lock with FSLogix you will probably also need to send a Memory Dump to troubleshoot FSLogix issues too.

    - Micah Adamson


    Wednesday, August 28, 2019 6:18 PM
  • VHDlocations is already set, not using CCD locations, I believe the issue is due to the Windows Search search, stopping/Starting and prevent the startshell.
    Thursday, August 29, 2019 8:38 AM
  • attaching my fslogix config..

    Tuesday, September 3, 2019 6:38 PM
  • Which event log are you finding the information about search service?
    Tuesday, September 3, 2019 6:41 PM
  • Im also seeing search errors and cortana errors. NOt sure why, I have cortana disabled.
    Tuesday, September 3, 2019 6:46 PM
  • here's a computer without fslogix installed. you can see login times much better
    Tuesday, September 3, 2019 6:48 PM
  • Hello BadWolf5150,

    Thanks for the additional information. I had my colleagues in support read through this thread today and they confirmed that you should open an FSLogix Support Request since they will need machine specific information from the FSLogix support tool to troubleshoot this issue further.

    Thanks.

    - Micah Adamson

    Wednesday, September 4, 2019 5:26 PM
  • We have the exact same issue. Did you find a solution?

    Thanks

    Wednesday, September 18, 2019 8:18 AM
  • We're also experiencing this same issue. We'll open up a ticket, but would also love to know if others in this thread have found anything interesting.

    In our case, it's relatively infrequent (5 or so service desk calls per day, and we have ~3k unique daily users). This issue was first reported right after we switched from traditional O365 containers to Cloud Cache (i.e. after disabling VHDLocations and enabling CCDLocations) about 2 weeks ago. Change was made via GPO, no edits to the machine image itself. FSLogix CLI, service, and driver versions are all 2.9.7117.27413.

    For individual users experiencing the issue, our service desk has been forcefully killing their VDI session, nuking the user's .vhd(x), .meta, and .lock files from both file shares configured in CCDLocations, and that has consistently fixed the issue for those individual users. HardlyMick's suggestion of a corrupted search index causing this seems plausible.

    Thursday, September 19, 2019 11:09 PM
  • Curious if other folks are having the issue with every login, or is it sporadic?

    FWIW, I did force corruption of the Windows Search database (mounted the virtual disk while no FSLogix agents were connected, opened SearchRoot\Search\Data\Applications\Windows\Windows.edb with a text editor, typed some garbage in the middle of the file, closed it, copied that to both CCDLocations shares), and launched another VDI session.

    No black screen, but we did see several events confirming the search DB was corrupt, it rebuilt, etc.

    

    I wouldn't rule out search corruption as a possible cause for this, but this specific test didn't produce the "black screen hang" our users have been reporting.


    Friday, September 20, 2019 7:20 PM
  • Hi Andy

    We're not using using cloud locations in our configurations.  We've haven't had black screen no issues for sometime now, however one RDSH is having the black screen issue this morning, despite search being rebuilt, restricted, office repaired etc.  I'll be checking to see if there was any 7042 and 7011 errors at the time of the reported black screen issues.

    Normally, users who have logged in before "search" timed out, crashed etc. are working fine.

    We have another ticket regarding upgrading to the latest client, so I'll mention it.



    • Edited by HardlyMick Monday, September 23, 2019 10:44 AM
    Monday, September 23, 2019 10:30 AM
  • KB4516061

    Addresses an issue that displays a black screen when you initiate a Remote Desktop Protocol (RDP) session. Not sure whether this resolves the black screen login delay experienced by some FSLogix customers remains to be seen.  Although we have non FSLogix customers who also experienced this issue on Windows 2016 RDSH, so will be testing shortly.




    • Edited by HardlyMick Wednesday, September 25, 2019 8:24 AM
    Wednesday, September 25, 2019 8:21 AM
  • Have you found a solution to this problem? We also get a black screen after login. It takes a few minutes for the desktop to appear. 

    Eventlog: The winlogon notification subscriber <frxsvc> took 200 second(s) to handle the notification event (StartShell).

    Regards Anish

    Friday, September 27, 2019 2:36 PM
  • Hi Anish,

    We're still waiting on a call back from MS support, and haven't found resolution yet. We do see similar events logged to the one you mentioned.

    The following event was logged approximately 8 minutes before the user reported this VM hung at the black screen. She reported that she was stuck at the black screen for approximately 10 minutes.





    Friday, September 27, 2019 7:57 PM
  • Hello,

    Could you please try to logon on the VM with an admin account (Without Fslogix container enabled) when the blackscreen occur for your user and stop the Appreadiness service on the console (Services.msc). If the black screen dissapear for your user then we've solved this issues with the last KB of M$ (Server 2019 DC)




    • Edited by Storn Tuesday, October 1, 2019 1:54 PM
    Tuesday, October 1, 2019 1:50 PM
  • Anyone found a fix for this issue? In our RDS 2016 environment we see the same black screen and server freeze completely.

    Our case:

    When an user logs in for the first time and the VHDX gets created we see the black screen. RDS VM freeze completely. We cant shut down the VM and need to power off to reboot it.

    Its a mixed environment with one old 2008R2 domain controller, rest is 2016 or 2019 server.

    When we disable our virusscanner (webroot) issue does not occur
    When we change VHDX location to same RDS host we logging in with webroot enabled issue does not occur.
    We have also created an test VM RDS 2019 and same issue occurs.

    In our test environment with only 2019 servers we have no problems with same fslogix and webroot version.

    After we reboot the RDS VM and the VHDX is created the user logs in fine.

    we see event 6005 in eventviewer.


    Wednesday, October 23, 2019 9:59 AM
  • We were seeing the same thing win server 2019 and version 1909, until we rolled back to FSLogix 1907 and it was all working as expected.

    Something buggy going on here.

    Friday, October 25, 2019 8:47 PM
  • Im still having this issue, even on a 2012r2 box.  Any other ideas?
    Thursday, October 31, 2019 10:57 AM
  • We have similar problems as mentioned in this thread, (Server 2016, Citrix VAD 1811, Citrix User Profile Management and FSLogix for O365 Containers). We also have F-Secure as primary AV.

    When users logon, (since friday november 22), they get the infamous "Black Screen" for up to ten minutes before properly logged on.

    However, in our case the problem was with Windows Defender and Real Time Scan of the users VHD-files at logon.

    Ran Set-MpPreference -DisableRealtimeMonitoring $true to test disable the Real Time Scanning and whoops, logon went back to normal again!

    So now we are uninstalling Windows Defender features on all of the affected servers and hopefully we are soon back to business as usual again:)


    Monday, November 25, 2019 12:57 PM
  • Hello, we have just received the following update: (This is from yesterday)

    Windows Defender signature version 1.305.2813.0 was published about 1 hour ago and should address this issue – and clients will update automatically in the next 24 hours. Impacted users can force an update (either from WU or from WD UX (or via manageability interfaces)). Please report if issues are still being seen with this indicated version.

    Regards,

    Brent
    Tuesday, November 26, 2019 9:15 PM
  • Hi!

    This is still very much an issue. Seems connected to creating a profile for a new user, as relogons for users with profiles are not affected.

    Anyone got any ideas?

    K.

    Wednesday, April 29, 2020 9:41 AM
  • Hi!

    This is still very much an issue. Seems connected to creating a profile for a new user, as relogons for users with profiles are not affected.

    Anyone got any ideas?

    K.

    having experienced the issues before and being able to reproduce the issue you describe this seems unrelated. We have recently introduced a self support reset option (powershell delete flagged container really early in de logon process) and noticed the black screen for 3 seconds while a new container is recreated. 

    The issue of the bug was different. it sessions were unusable for existing users for minutes.

    Thursday, April 30, 2020 10:46 AM
  • Hi

    We are having the same exact problem.

    We are using Citrix profile management with FSLogix for outlook search roaming.  However it takes a long time for a user to logon (over a minute) and then there is a black screen that stays up for up to 20/30 seconds before all the icons show up on the screen.

    Nothing in logs or event log has been useful.  We have done all the necessary AV/Profile exclusions.

    Can anybody help please?

    Friday, June 26, 2020 2:22 PM
  • We are having the same problem, but even worse.

    If the users come to an black login screen the stay there. 
    The admins have to logoff the user per hand.

    In the eventlog we have this error message:

    "A timeout (30000 milliseconds) was reached while waiting for a transaction response from the frxsvc service."

    We have 8 remote desktop server (Win Server 2019 Standard) but only 2 of them have this problem.

    We installed the server 2 month ago and the problems began in the last two weeks and keep getting worse. 


    • Edited by X_mg Wednesday, October 21, 2020 11:19 AM
    Wednesday, October 21, 2020 10:00 AM