none
Black screen on login after upgrade RRS feed

  • Question

  • Hey all,

    I'm running into a challenge with upgrading our FSLogix RDS environment from 2.9.6842.37624 to 2.9.7205.27375 after a few failed attempts now. After running the upgrade either in place or via uninstall, reboot, install new version, reboot; we get black screen on logon for any profile container accounts. Our FSLogix setup is pretty simple a 2016 RDS session host, 2016 DC pushing out GPO for profile containers, and a dedicated 2016 FS for FSLogix containers, all Server standard 2016 (currently no 3rd party AV). Install looks to go properly and when I check logs while a container supported user logs in everything appears to be successful, no errors no warnings on either the FSLogix programdata logs or in event viewer... the account just gets stuck on a black screen indefinately (I gave it 40 minutes on a session host that normally takes around 15 seconds to complete login, trying multiple accounts post reboots) and eventually things on the server local user hangs like a service or driver is getting stuck.

    I'd open up a support case but we've had to rollback the VM checkpoint to get staff working again after our couple of attempts thus far, so logs are now gone, so I am trying to find some direction on either where to look or what to do differently for our next attempt to get our session host upgraded so we can get a solid process before doing so on our client's deployments. 

    Tuesday, November 5, 2019 6:31 PM

All replies

  • Did some digging. 
    2.9.7205.27375 logins fail every time and will eventually hang explorer.exe system wide.
    Looks to be related to windows search service, as I'll get an error in event logs (followed by a further cascade of search service errors, logon taking too long, and eventually app hang for explorer.exe). I found a interesting 'workaround(ish)' in that if I go into indexing options as a local admin user, rebuild index before logging in with a profile container users, login and apps work, but upon logoff it freezes up and get another search error. If I carefully time the logoff with another rebuild on indexing logoff works. 

    We dug around and found a slightly older version 2.9.7117.27413, and the issue does not occur if we roll back to that. 

    This is what I get for initial login search service error:

     Log Name:      Application
    Source:        Microsoft-Windows-Search
    Date:          11/7/2019 11:23:43 AM
    Event ID:      7042
    Task Category: Search service
    Level:         Error
    Keywords:      Classic
    User:          N/A
    Computer:      ---redacted--
    Description:
    The Windows Search Service is being stopped because there is a problem with the indexer: The catalog is corrupt.

    Details:
    The content index catalog is corrupt.   0xc0041801 (0xc0041801)

    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-Search" Guid="{CA4E628D-8567-4896-AB6B-835B221F373F}" EventSourceName="Windows Search Service" />
        <EventID Qualifiers="16384">7042</EventID>
        <Version>0</Version>
        <Level>2</Level>
        <Task>1</Task>
        <Opcode>0</Opcode>
        <Keywords>0x80000000000000</Keywords>
        <TimeCreated SystemTime="2019-11-07T19:23:43.284064600Z" />
        <EventRecordID>125587</EventRecordID>
        <Correlation />
        <Execution ProcessID="0" ThreadID="0" />
        <Channel>Application</Channel>
        <Computer>--redacted--</Computer>
        <Security />
      </System>
      <EventData>
        <Data Name="ExtraInfo">

    Details:
    The content index catalog is corrupt.   0xc0041801 (0xc0041801)
    </Data>
        <Data Name="Reason">The catalog is corrupt</Data>
      </EventData>
    </Event>



    Thursday, November 7, 2019 8:34 PM
  • Thank you for the report.  This was an unfortunate regression in the 1909 FSLogix release.  A Hotfix build is now available for this, but is being released more slowly and to early adopters first to ensure higher code quality.  Support has been asked to give the release to any customers hitting this issue.  Please open a support ticket and let them know that you have hit the 1909 deadlock issue, and they should get you a link to the fix.  We hope that some testing improvements, and an early adopter program will help us prevent this type of regression in the future.
    • Edited by Brian Mann1 Saturday, November 16, 2019 12:40 AM
    Saturday, November 16, 2019 12:40 AM