none
please wait for the system Event Notification service

    Question

  • Hello all, 

    Recently a Windows 2008 server is displaying the following message when users (admins) try to log off from RDP sessions 

    "please wait for the system Event Notification service"

    This issues occurs this morning, A user will go and log off and he will get "Please wait for the System Event Notification Service..." on his screen.   Then it seems it starts to affect others during the course of a few hours.

    I try and manually log the user out from task manager and even tried to reset the connection from Remote DesktopServices Manager.  

    Basically the only way to get everything working again is to reboot the system.

    Anyone have any ideas on this screen? and why it is freezing at this point?
    Sunday, November 08, 2009 9:23 PM

Answers

  • Hi Harro,

    Thank you for posting in windows server forums,

    Have you enabled SENS ?? or does any of your applicaiton running on server Uses SENS ??
    • Marked as answer by David Shen Monday, December 14, 2009 7:17 AM
    Saturday, November 28, 2009 3:39 AM
    Moderator

All replies

  • Anyone? 

    Really need help on this.... it is also affect our Citrix servers, when users are logging off, it is halting on this screen....
    Monday, November 09, 2009 5:24 AM
  • Hi Harro,

    Thank you for posting in windows server forums,

    Have you enabled SENS ?? or does any of your applicaiton running on server Uses SENS ??
    • Marked as answer by David Shen Monday, December 14, 2009 7:17 AM
    Saturday, November 28, 2009 3:39 AM
    Moderator
  • I am getting the same message.  I dont know if any of the applications is using SENS.  The server does not even take a soft boot.  It has to be hard booted as it continues to display this message.  Should I disable SENS?  What are the ramifications of doing that?
    Wednesday, February 10, 2010 5:59 PM
  • Getting the same thing here. Win2008 R2 (64bit).
    Thursday, February 11, 2010 5:43 PM
  • Hi Sainath,

    My customer is having the same problem on his Win SBS Std 2008...when we log off an RDP session he gets:

    "Please wait for the System Event Notification Service..."

    It just hangs there.  He's running Exchange.  It seems like the only option is to power off.  Is that the only solution?

    Thanks,

    Kim

    Sunday, February 14, 2010 12:35 AM
  • Hello,


    Getting this Same Error on a Brand new Windows 2008 SBS installation.  However it is blocking log in currently.  When I get onsite later today I will try and find any errors in the log and update this forum.

    Thanks,
    Brad
    Friday, February 26, 2010 12:22 PM
  • I am also experiencing the same issue as below:

     

    Please wait for the system Event Notification service message displays intermittently on a Remote Desktop client upon logging off.  This message freezes the client's computer as well as prohibits any other users from logging into Server 2008 RDC.  This following System Event occurs several hours prior to the "please wait for the system Event Notification service" message hanging the computer. 

    The COM+ Event System detected a bad return code during its internal processing.  HRESULT was 80070005 from line 147 of d:\longhorn\com\complus\src\events\tier2\security.cpp.  Please contact Microsoft Product Support Services to report this error.

    The 2008 physical server will also hang at the please wait for the system Event Notification service message upon logging off.  The only way to reset the system is a hard reboot.  In the Terminal Services connection manager, all users, even those with disconnected sessions will still be displayed. 

     

    It looks like an issue occurs when one of the users logs off.  It has occurred 4 or 5 times since we started this.  There is always a COM+ event notification a few hours before the total system locks.

    Sunday, March 07, 2010 5:52 PM
  • Same issue here as well, Server 2008 x64. It has happened several times. Any word from Microsoft on this?
    Friday, March 26, 2010 9:02 PM
  • Well, we ended up finding a work around that eventually worked. It wasn't too great of a process. We used the services.msc to connect to the server and stop the System Event Notification Service (after it had been stuck for an hour or longer). It got stuck in the stop_pending (3) -- Stopping state.
    We then did a remote desktop session to it (same user that caused the "Waiting for the System Event Notification Service..." message), and it went to a black screen. On the actual server, the Waiting for the System Even Notification Service went away and let us log in as a different user.

    From there, we did a: sc queryex sens
    This allowed us to find the PID.

    Then, we did a taskkill /PID <PID#> /F and stopped it. Then we had to reboot the server completely, but at least it let us reboot.

    Hopefully Microsoft comes up with a fix for this issue.

    Friday, March 26, 2010 11:40 PM
  • Also having this annoying bug on 2008 R2 x64 with XenApp 6.0 final and also waiting for a solution, sigh, this thread is started 4 months ago, and still no solution ?

    Sunday, March 28, 2010 1:43 PM
  • Hello everybody,

    Same problem here.  We have it on Windows 2008 Standard & R2.  Could it be network-related?  Today, I tried to reach a computer on my network (within a terminal session).  The server hung on this action (the computer nor network had problems, I could ping etc...).  When I tried to logoff (in my terminal session), we got the "Please wait for the system event notification service".  I tried the workaround from "rmoat", but I did not succeed to restart my server regularly. I could not stop the SENS-service (even not with the taskkill-command).

    It happens every two or three days and I can't find a situation in which it always happens. The only thing that helps me a bit, is NOT logging off in a terminal session, but just close it.  Not the right procedure, but it helps.

    The Com+ - event doesn't appear, but I don't wait for hours to reboot my server. 

    ----> little correction <-----

    Today we had the problem again, and this time, we had also a Com+ - event in our logs.  So, exactly the same problem. 

    Hopefully Microsoft comes with a fix...

    • Edited by Thomas Hoste Friday, April 02, 2010 9:11 PM correction
    Tuesday, March 30, 2010 5:28 PM
  • I am having this same issue too.  The Please Wait identifiable if I RDC into the server, and the black screen. Windows 2008 R2 x64. Latest drivers all updated.
    Thursday, April 01, 2010 10:38 AM
  • could it be Office Communicator Client related ?

    http://forums.citrix.com/thread.jspa?threadID=261933

    Tuesday, April 06, 2010 6:10 AM
  • Hi Guys,

     

    Same issue here. our diagnosis so far is: we had a Memory leak, caused by McAfee Virusscan 8.7, droppped this down to 8.5 and that has corrected it on all servers, apart from 1. we get COM+ errors in th logs in quite a few, but this seems to have no relevance on the SENS issue. we have 1 SBS2008 server now that seems to hang on reboot, (Reboot because the performance has dropped off, and we have users that cannot access files) hangs on the SENS warning when rebooted. have to hard reboot. we are only running exchange.

    Tuesday, April 06, 2010 11:07 AM
  • Hasa anyone tried disabling SENS? Sens is enabled by default in SBS2008 as far as i can see. can we just turn it off?
    • Proposed as answer by Zina Pozen Wednesday, April 07, 2010 9:10 PM
    Tuesday, April 06, 2010 11:50 AM
  • A non-responsive ISensLogon subscriber can cause a hang at logoff time. 
    A 3-minute timeout has been added per-subscription for Win7/R2, but if there are multiple subscriptions, it wouldn't necessarily help.

    Persistent subscribers on the system can be found here:
          HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EventSystem\{26c409cc-ae86-11d1-b616-00805fc79216}\Subscriptions 
    Can someone take a look and report what they are seeing?

     

    Thank you!

    (there are also transient subscribers which can be discovered by running a script - we'll try to post one soon)
    Wednesday, April 07, 2010 9:24 PM
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EventSystem\{26c409cc-ae86-11d1-b616-00805fc79216}\Subscriptions\{F98C5003-16F4-4E33-BCA4-E92F4742AD27}-{00000000-0000-0000-0000-000000000000}-{00000000-0000-0000-0000-000000000000}

    Have put Image of Key and contents on our website here:

    http://www.af-it.com/wp-content/uploads/2010/03/Registry-Details-for-Technet-Forum.jpg

     

    Thursday, April 08, 2010 10:25 AM
  • Hello,

    Two images of the key.  I don't have the "Subscriptions" on a Windows 2008 standard, only on a Windows 2008 R2.  The problem happens on both versions. 

    Screenshot of both versions:
    http://www.coltdlln.be/Win2k8_DC.jpg
    http://www.coltdlln.be/Win2k8R2_Exchange2010.jpg

    Hope this helps somebody...

    Thomas

    Sunday, April 11, 2010 12:27 PM
  • Hello

     

    In my Case, it was the McAfee VSE 8.7 SP3 Virusscanner

    After Reinstall McAfee the problem was solved.

    Cheers

    MasterB

    Tuesday, May 11, 2010 7:17 PM
  • Hello,

    We are running TMG on a fresh Windows 2008 R2 installation.

    - Unfortunately no McAfee VSE where reinstallation would solve the problem.

    As I read in this postings, it happens to Windows 2008 R2 with

    Applications like: TMG, Exchange 2K10, OCS, McAfee ...

     

    Any new Ideas for this problem?

    Kind regards

    Christoph


    Sysadmin
    Thursday, May 27, 2010 10:38 AM
  • We are having the same Issue here,

    We are running 2 server with Windows 2008 R2 and Citrix Xenapp6 under a IBM Bladeserve

    r HS21 XM with BootFromSAN. We don't have any NIC Teaming actived and we have installed McAfee Virusscan 8.7 in one server, and no antivirus in the other to test it, and we are having the same issue in both of them.

    We are using MS Communicator 2007 R2, but we have applied the last hotfixes and patches in the server and client side:

    http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=515d6dba-4c6a-48bb-a06a-d99c5742676d

    It is happenig every morning wince we put the second XenApp6 server on our new farm. The symptoms are:

    • One user get his session hang, so when we try to force close it we get the message "Waiting for system event notification service" and the user sessions never close.
    • When it occurs other users CAN log in, but any user that try log off get this message.
    • The users that have active sessions CAN work.
    • The remote desktop and citrix management console show the user as Active, but it can close the session.
    • If trying to restart the System Event Notification Service (SENS) the service get stuck on Stoping


    There is a link to a Citrix forum talking about the same problem:
    http://forums.citrix.com/thread.jspa?threadID=261933&tstart=0
    Friday, July 02, 2010 9:43 AM
  • Just hit the same error messaage.  I had to use prcess monitor to kill the svchost.exe process running the event manager process and reboot the box.
    Friday, July 30, 2010 4:34 PM
  • Having this on a Windows 7 user logging in just today, this is in there with a huge wait 1 hour for Group Policy Printers processing to complete then a huge wait of so far more than 2 hours waiting for the SENS before able to complete logon.

    While the system is still displaying this message and seems to be stuck on it I am able to open the Event Viewer remotely from another computer with some stuff in the event log such as:

    The winlogon notification subscriber <GPClient> took 3593 second(s) to handle the notification event (Logon).

    (We get this randomly. A system will be fine then for no apparent reason it will take an exceptional length of time to process some part of the logon)

    The last three events in the Applications event log over a 2 hour period are the same:

    License Activation Scheduler (sppuinotify.dll) was not able to automatically activate.  Error code:
    0x8007232B

    Basically the timeframe for getting this computer up today is:

    Turned on at 12:47 pm.

    The system started up normally and was idled until 13:55 when a user logged on with Privileges:        SeSecurityPrivilege
                SeBackupPrivilege
                SeRestorePrivilege
                SeTakeOwnershipPrivilege
                SeDebugPrivilege
                SeSystemEnvironmentPrivilege
                SeLoadDriverPrivilege
                SeImpersonatePrivilege

    At 14:55 get an error as above, the winlogon notification subscriber took 3593 seconds.

    Then after that, more or less randomly through to 16:47 there are three events all the same as above, License Activation Scheduler (sppuinotify.dll) etc.

    In the System log looks more or less normal except for five errors from Service Control Manager all 14:55 - 14:57

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

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

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

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

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

    Can't see anything else in any other event log.

     

     

    Wednesday, August 11, 2010 5:40 AM
  • Some more digging and apparently this is

    SPP Notification Service

    Something to do with software activation / authentication

    This is a fully licensed activated installation of Windows that was activated with our MAK (I see the error sometimes come up on KMS servers, this computer is a desktop, it is not running KMS server)

    Wednesday, August 11, 2010 5:52 AM
  • Well after waiting for a long time till 18:01 I logged into the services remotely and tried to stop the SENS service.

    As it could not stop I reset the system.

    Note that all of the above was experienced on a Remote login rather than directly logging in at the computer (before resetting I went to the computer and it displays Press Ctrl Alt Delete to login but the remote window is still displaying Please wait for the SENS etc.

    The next try is a direct login, at this point we are told the system is not activated.

    Activation was carried out successful but there was never any indiciation with remote logging in there was an activation problem.

    Pretty sure all the other systems eventing random login delays and please wait for blah blah blah are fully activated.

    Wednesday, August 11, 2010 6:13 AM
  • Hi Guys, havent posted for a while on this, so the issues you are having may be slightly different to mine, or things may have changed.

    We have found the answer to the issue we are having: our issue was - Server hangs, as if it were a memory leak. SENS etc. Server stops working. hit the button etc.

    Cause (Confirmed)- McAfee Viruscan, 8.5 or 8.7 at any patch level, causes the issues discussed here, when there are clients accessing the machine, and you change the USB drive used for backup. There is no option but to reboot the machine, and then the process starts all over again.

    Fix, there isnt one, we have, and are still, discussing this with McAfee, aparently, its virtually all the Antivirus products that are having this issue, there is no fix as of yet, but we are running several test machines and working with them to find one.

    Recommendations - (bad i know, but never the less, needs to be done) Run the server without antivirus software for the time being. This is not ideal, but due to this issue we have had t do full restores on 2 customers systems, as they have become damaged during the hard reboot process. as soon as we get the fix delivered, i will post it up here.

    Friday, September 10, 2010 1:32 PM
  • Hello colleagues.

    Here is solution, that works for us:

    1. Find latest warning events in Application logs #6005 and 4627. Usually this happens, and problem appear after this.

    2. Find subscriber name in event #4627, and application responsible for this. For example that is "Messenger ISensLogon Subscriber". That is MSN messenger.

    3. Finally check for Disconnected users in Remote desktop services manager and using Task Manager - kill this process for this disconnected users. Like msnmsgr.exe. After killing - all session should be closed properly (or you can log off them manually if necessary).

     

     

    • Proposed as answer by synchronIT Wednesday, October 20, 2010 2:08 PM
    Wednesday, October 20, 2010 2:06 PM
  • i was very surprised that during the year Microsoft do not propose any solution or fix....

    As i understand hanging process is using SENS service and do not give possibility to others to log off..

    Wednesday, October 20, 2010 2:08 PM
  • I'm have the same problem, and found a cause, if not the reason: MS Messenger. Every time a Remote Desktop session log-off hangs with "please wait for the system Event Notification service", some user´s Messenger is "eating" an unusual amount of processor time.

    I just kill the Messenger task and immediately every hung sessions closes.

     

    I have Windows 2008 R2, but my ant-ivirus is Kaspersky, not McAffe.

    Wednesday, November 03, 2010 6:19 PM
  • I just ran into this today on one of our customer managed Windows 2008 Servers.  Unwilling to accept "Do steps 1-10 and then restart server" as an answer, I poked around a bit and was able to work-around the issue.

    First, to confirm for others, how this issue presented itself.  Upon logout of an RDP session, logout hung at "Please wait for the System Event Notification Service...".  I was able to establish additional RDP sessions, but each session was faced with the same result.

    Eventually I logged on to the /admin (previously /console) session with an alternate Administrator account.  Using Server Manager or services.msc I located the "System Event Notification Service" and told it to restart.  The restart failed on "stopping", having never stopped, it couldn't restart.

    Running "Task Manager" I selected the "Services" tab and located "SENS".  Performing a right-click on the SENS service, I selected the "Go to process" option.  This changed to the "Processes" tab and automatically highlighted the "svchost.exe" process which was running the SENS service.  I again right-clicked this process and selected the "End process" option.  It took close to a minute, but eventually the process ended and the "System Event Notification Service" changed from "stopping" to "stopped" in Windows Services.  At this point, I reviewed the "Users" tab in Task Manager and noticed that my previously stuck Terminal Sessions had finally reset.  Back in the services control, I started "System Event Notification Service", which started without issue.

    Now, this has only seemed to be a work-around, as upon my next RDP logout, the "Please wait fro the System Event Notifications Service..." message returned, however, if you have gotten all of your Terminal sessions stuck, this should help to clear them out.

     

    ~Ninet4

    Monday, November 08, 2010 9:15 PM
  • Found the problem. It was Live Essentials 2011, the new messenger. Removed it from the server and good to go!

     

     Dave

    • Proposed as answer by dcrepeault Wednesday, November 10, 2010 2:32 PM
    Tuesday, November 09, 2010 5:11 PM
  • don't have live essentials or any messenger software, but i do have the symptoms. The 4627 event pointed to explorer.exe.

    I do have mcAfee 8.7 and Progress OpenEdge 10.2B.. I don't know what it all has in common with the new live messenger. Anyone?

    Monday, November 15, 2010 10:26 AM
  • BUMP!!!

    still having this annoying problem (@*#)(!*

    seems like Lync 2010 (RTM) communicator.exe (which I cannot kill) is causing the problem, tried everything, but when I kill svchost.exe (which the SENS service pointed to), it kills a lot of services and my session gives me a blank screen (the one telling me "please wait for the event notification service" before).

    SIGH

    Thursday, December 09, 2010 11:32 PM
  • I am having the same problem. Other uses are able to login fine, it just my TS session is stuck at "please wait for the system event notification service" message. Any word from Microsoft on this thread?
    Saturday, December 18, 2010 4:17 AM
  • I started seeing the same issues with several of my 2K8 R2 64-bit servers. Found this link on a citrix forum.

    http://support.microsoft.com/kb/2383928

    After I did the install all of the RDP sessions are logging out correctly. Hope this helps.

    Monday, December 20, 2010 3:52 PM
  • HI,

    Since we installed this Hotfix the SENS issue had not hapened again.  

    http://support.microsoft.com/kb/2383928/es

    We are taking a monitoring time before taking this hotfix as a solution, but we added another TS node to our Citrix Farm without this hotfix and the SENS issue apeared only in this new node, so it seems to be the good solution.

     

    Monday, December 20, 2010 4:05 PM
  • We have the exact same symptoms on an SBS 2008 box.  Can anyone else confirm the same?

    The 2383928 hotfix won't install saying "the update does not apply to your system".

    Have been on the phone to Microsoft to see if the hotfix is avail for SBS 2008 but was given the run around and left on hold for too long.  Will have another attempt later.

     

    Daz

    Monday, January 17, 2011 6:34 AM
  • I think its been figured out. We are running Server 2008 R2 remote desktops (3 of them). Once in a while we have the same problem with all 3 of them. restarting the server fixes it but its not practical as the users are connected and doing their stuff.

    When I had this problem in the morning today, I logged on to another server and fired up Remote Desktop Services Manager, and connected to the server, the one had the problem. And from there I could see all running processes. I killed all office communicator processes (Communicator.exe *32), tried to log on to the server and it went through. 

    • Proposed as answer by JSneade Wednesday, February 16, 2011 6:50 PM
    Tuesday, January 25, 2011 3:51 PM
  • Anyone found a fix for WIndows 2008 (not R2) x64? The hotfix suggested above is for R2...?
    Ced418
    Monday, February 21, 2011 5:17 PM
  • Same issue on Server 2008 SP2, anyone know of a fix?
    Wednesday, March 09, 2011 4:16 PM
  • The same issue with SBS 2008 :(

    It looks like the problem is not solved for the server 2008 and SBS2008?

    Monday, May 09, 2011 2:39 PM
  • Sames issues on SBS 2008.

    Only way I can get the server to restart is to do a taskkill for the PID of sens.


    Monday, May 09, 2011 10:48 PM
  • Any news on this anyone ? Getting this on a new SBS2008 install and also getting it on a 2008 DC installed about 18 months ago One RDP account sems to be stuck logging onto the SBS2008. And another administrative account is stuck seemingly logging off waiting for SENS.. Anyone know of a fix from Microsoft yet ?
    Tuesday, May 17, 2011 12:35 PM
  • I'm getting the same issue on a Server 2008 Standard SP2 and like most others, nothing but a hard reboot will fix it.

    One thing I've noticed:  We use Altiris (or now Symantec Management Agent) and occasionally, the agent will show inactive in our management console even though the service for the agent is still running.  When I see one of our 2008 servers showing as inactive, you can pretty much bet that the next time you RDC and log off you'll get the 'wait for SENS' issue.  Symantec uses the SENS service apparently.  Don't know if this will help anything, just thought I'd throw it out there.

    • Proposed as answer by szybki_filozof Wednesday, May 25, 2011 12:38 AM
    • Unproposed as answer by szybki_filozof Wednesday, May 25, 2011 12:38 AM
    Monday, May 23, 2011 7:57 PM
  • I have a very basic appearance of this issue as follows:

     

    Dell R300 with latest bios and other.

    2k8R2 with all updates

    No Anti-Virus software, no office software, no SBS etc (hotfix above would not apply)

    AutoAdminLogon of console user (administrator)

    First RDP conection and shadow console works just fine.  After closing shadow session, when I try to reopen shadow session, get black screen and system freezes locally.  Remotely can do stuf on RDP session and can kill shadow.exe  but can't touch any processes in console user session.

    I've been doing this with W2k8 (non-R2, 32-bit) for years with no issues and I'm really NOT happy that this issue is still not addressed!

    ANY help would be appreciated!

    Ed


    Thursday, May 26, 2011 1:11 PM
  • All,

     

    I found and use the steps in this link I found: http://mikefrobbins.com/2010/11/04/please-wait-for-the-system-event-notification-service/

    I don't ever see what he has in step 2.  I just use steps 3 - 8.  I usually put the server in Drain Mode.  Then wait till all users log off and reboot the server.

    I have been unable to determine the root cause.

    Thursday, May 26, 2011 5:21 PM
  • We've had the same issue and have found a different way to resolve the issue which does not require a server reboot.


    Start Remote Desktop Services Manager
    Identify the user ID in the Users tab
    In the Processes tab sort by ID
    Go down to the user ID and end the winlogon.exe process
    the user session will be logged off
    A server reboot will probably be beneficial at the end of the day

    Thursday, September 08, 2011 3:15 AM
  • This issue will occour in my environment on a random server every few months.  I perform the same steps to get the users off by killing their winlogon.exe process and reboot the server at nite.  After reboot the server will be fine for a few months and a different server will get the dreaded "please wait for system event notification service" msg. 

    I'm currently running windows 2008 x86 with Xenapp 5.0.  I've installed all proposed service packs and hotfixes recommended from Citrix and Microsoft.

    From my stand point this is a Microsoft bug as I can repoduce this error when I RDP in a server. 


    GEEEZ MICROSOFT  thanks for the headache !

    Wednesday, September 21, 2011 8:05 PM
  • I wanted to follow up with what I've found to be a more stable workaround than killing the svchost process tied to SENS.

    We use Symantec Endpoint Protection and Altiris (Notification Server).  Both of those agents use the SENS service to send alerts back to their respective management consoles.  I noticed every 3 or 4 days our 2008 boxes would stop polling to the Altiris console and the agent on the box would not respond (but the process was still running).  When this happens, it was a sure bet the next RDP session would get the SENS error on logoff.  When I tried to kill anything associated with SENS or Altiris, I would get an access denied message.  What I believe was happening was A. The Altiris agent somehow kludged up the SENS service.  B. The Endpoint Protection agent was preventing me from ending the Altiris process.  C. I never got a notification that SEP was blocking my taskkill attempts because it was using the SENS service to send those events.

    Now all I have to do, if I notice the box has stopped responding to the Altiris console, is disable the SEP agent and kill the Altiris agent process.  The agent will restart itself and resume polling.  At this point I don't get the SENS message at logoff, and it continues to work for another 3 or 4 days.  It also allows the server to shutdown or restart.  This beats having to hard reboot, or find the svchost of the SENS service and kill it EVERY TIME a user locks their RDP session.

    This may not help anyone other than those using both SEP and Altiris, but maybe someone more experienced than I can use this to figure out the real problem :D 

    Friday, October 21, 2011 2:46 PM
  • Thanks You!!! Its really helped me..
    Sunday, November 13, 2011 4:54 AM
  • I'm having the same issue Orgswami mentioned, hope for a solution.

    A periodic boot it not a suitable option!

    Thursday, November 17, 2011 8:54 AM
  • I was able to force the server past the "please wait for the system Event Notification service" message by logging into the server on the same username through an iLO2 console. After reading this thread I noticed someone saying removing Windows Live fixed the problem. While I didn't have Live installed, I did have Lync Client installed. Upon removing this program I have not had the error since.

    Saturday, December 03, 2011 4:01 PM
  • I noticed this problem with my RDS servers.  I have folder redirection enabled and those redirected folders are going to folders with windows compression enabled.  I disabled the compression for the profile and things have been pretty stable.  When the user logged in, I noticed in the file server a whole bunch of files open for the user trying to log in which were basically stuck.  I closes all of those files from the file server and disabled the compression on the folder that holds the redirected files and that did it for me.  I know that this error can mean a lot of things, but in this case, this solution worked for me.

    -Ron

    Tuesday, February 07, 2012 4:08 PM
  • This issue for me seemed to be related ISCSI target using domain authenication and CSV. After removing the CSV from the cluster and testing the volume was indeed intact. Added the CSV back and Hyper-V and Failover Clustering starting behaving correctly. And lastly the system event notification service event hang went away. Haven't gone through the logs yet but just FYI for any Hyper-V ISCSI Failover Clusters seeing similar results.
    Wednesday, February 15, 2012 5:56 AM

  • Just to add my experience, I have been having backup issues so to get a copy of the data we connected a USB HDD to a Windows 2008 server. Once the driver had loaded I would see the server begin to struggle. The sessions would not log out due to the Event Notification service and after reboots the server would spend a long time applying group policy

    Removed the USB drive (via disabling the USB ports as the server is remote) and the server is good again.

    Thursday, May 31, 2012 10:12 AM
  • @RJ-45:

    Thanks, this appears to have done the trick in our case.  XenApp 5 on Windows 2008 SP2, users couldn't log off and killing sessions would not work.  Two instances of communicator.exe existed on the system (both happened to be for disconnected users).  Once gone, the stuck sessions cleared themselves.

    Thursday, June 07, 2012 10:22 PM
  • I am having this issue and I am using Windows Server 2012.  I have a Hyper-V Failover Cluster and a iSCSI SAN for storage.  The issue happens when I try to restart the server, and I have waited for hours.  To be able to remotely restart the server, I used a tool called "SCCM Client Center", which lets me connect to the remote processes and kill the SVCHost.exe, then the server restarts.  Looks like this issue has not been fixed yet on the new Windows version.


    Monday, March 04, 2013 4:02 AM
  • Hi All,

    Even i had this issue and I was able to fix this without even a reboot of the server .

    whenever you face this issue, check the application event log and you will find something like below

    Log Name:      Application
    Source:        Microsoft-Windows-EventSystem
    Date:          6/4/2013 6:20:27 AM
    Event ID:      4627
    Task Category: Firing Agent
    Level:         Warning
    Keywords:      Classic
    User:          N/A
    Computer:    *******
    Description:
    The COM+ Event System timed out attempting to fire the Logoff method on event class {D5978650-5B9F-11D1-8DD2-00AA004ABD5E} for publisher  and subscriber .  The subscriber failed to respond within 180 seconds. The display name of the subscription is "ISensLogon2". The HRESULT was 80010002.

    which means that this service is having an issue, don't try to restart the service by going to services as this may fail for restart or may even not cleanly unload the handle.

    Open the Process Explorer (sys internal tools) and sort for svchost.exe process and now check properties of every svchost.exe process .

    After opening properties on each services make sure you  select the Services tab and look for the display name (in my case COM+ Event System).

    once you get the right svchost.exe, select the process & click Restart, once the process restarts , your issue will be fixed.

    Now try log off from the server and you wont have the issue.

    This doc even helps in case your facing issues of logged off users showing in task manager .


    Windows Server System Administrator


    • Edited by Pankajvg Tuesday, June 04, 2013 11:03 AM
    Tuesday, June 04, 2013 11:00 AM
  • seems like same server, 2012 and Hyper-V.

    Yesterday, it was fixed to reboot since last week. however, I'm afraid that it will be come again, because I don't know why it happened.  Does anyone tell me why and how?


    Jun Ohama

    Tuesday, August 13, 2013 3:25 AM
  • Have continued to experience same hang upon logoff at the "Please Wait For The System Event Notification Service" message across a variety of Win7 OS Desktops and Laptops... the one theme, they all are Dell's using a Dell NIC or Wifi NIC service layer... that of Broadcom or Dell WLAN service.  After uninstalling the suite and only applying the drive, message hang no longer takes place. As others have found, either message hang tied to antivirus service too.  As we use Symantec enterprise wide, this has not been reported to that... but no doubt that the SENS service is getting stuck on the pending termination of another process...

    Tuesday, September 17, 2013 6:29 PM
  • I'm having the 'Please Wait....' message on new Dell 7010's that are deployed via WDS - Windows 7 64 bit.  I'm interested in UW Tech's post as it sounds similar to my experince but I don't understand the part about uninstalling the suite, where's this, how do I find what to uninstall?  Any help on this would be appreciated.
    Tuesday, October 08, 2013 10:54 AM
  • This answer from <cite class="fn">Jeff Fogel</cite> solved my problem on Windows Server 2008 R2: The system event notifacation issue isn’t an issue with Windows Live messenger… Read below on what I have found.

    The fix for this issue is very simple.

    First we will examine what causes the issue to begin with. The cause is the COM+ Event Service detects a bad code and hangs. When you go to services.msc you won’t see the service hang but believe me it is. If you try to stop the server you will then see it hang and you won’t be able to get it back started. You can’t kill the process via taskmgr because its a svchost.exe service so you’ll never know which one to kill unless you download a little program call Processor Explorer from Sysinternals.

    1. Open Eventviewer and select Application and filter the list so all you see are Error logs

    2. Scroll through al Error logs till you come to one EventSystem (EventID=4621) (The COM+ Event System could not remove the EventSystem.EventSubscription object {C986B80D-E6CE-4FB0-9A44-F19BF27C165A}-{00000000-0000-0000-0000-000000000000}-{00000000-0000-0000-0000-000000000000}. The HRESULT was 800706be.)

    3. Ok now open Process Explorer and sort by process name

    4. Find the list of svhost.exe and start right clicking each and selecting Properties.

    5. After hitting Properties on each services make sure you are selecting the Services tab and look for the svchost.exe process that has the EventSystem service which its display name is COM+ Event System

    6. Now close the box and right click on the svchost.exe process and select Restart

    7. Instantly once the service shuts down and restarts you will notice in your taskmgr that the users that were hung are now gone and they can now login and logout as they please

    8. There are some services that won’t start back up after restarting this service so make sure you go back into services.msc and sort services by automatic and start up the ones that aren’t running.

    This should resolve your issue until you get another SystemEvent error in Event View, but then just follow these steps and you are fine. The greatest thing about this fix is it doesn’t requrie a reboot like all the millions of thread out there about this issue, because the issue isn’t resolved by a reboot.


    I think the world is run by 'C' students - Al McGuire

    Wednesday, October 23, 2013 9:35 AM
  • Quick fix...RDP into the machine as any admin user, open task manager, go to services tab, find SENS and right click on it then choose "go to process" and end the process. Life will improve :-)
    • Proposed as answer by Clay V Tuesday, October 29, 2013 1:12 AM
    Tuesday, October 29, 2013 1:12 AM
  • Um well you can go through all that if you really want to but...

    Quick fix...RDP into the machine as any admin user, open task manager, go to services tab, find SENS and right click on it then choose "go to process" and end the process. Life will improve :-)

    • Proposed as answer by Clay V Tuesday, October 29, 2013 1:16 AM
    Tuesday, October 29, 2013 1:16 AM
  • This issue has plagued us for almost a year on a Windows Server 2008 Enterprise installation. We tried the hot fix, learned how to disconnect users without having to re-boot the server, and even learned that if you don't LOG OFF the issue doesn't rear its ugly head.  However, all the work arounds were NOT a fix for the true problem.

    There is no doubt, there is a bug in this OS that is causing this. Certain programs trigger that bug and the SENS process can not complete the log off.  After reading this forum several times, it finally hit me when people were talking about MS Messenger causing this.  

    Our client uses Yahoo Messenger to communicate with co-workers all over the country.  They also use RDP for 90% of their work in the office so they wanted Yahoo on the server so all users would have access to it.  In the beginning we had errors with Yahoo, so we did away with it and had no problems.  One of the users decided she wanted it back so she installed it on her RDP desktop ( she was management and an Admin ). It worked on the surface without errors so others started using it too.  That's when the problems began with the SENS lock ups. 

    A search of the System and Application Event logs showed a Yahoo error occurring before each SENS event. Sometimes minutes, sometimes hours before.  The SENS event did not appear until a user attempted to log off after the Yahoo error.  Once one user locked, everyone did from then on until either the system was restarted or users WinLogOn process was closed using the RDP manager.

    Friday, we made a decision to try removing it as we had tried everything else.  NO MORE SENS ERRORS.  I also went to Yahoo's Support page and found they do NOT support any version of Windows Server which at one time they did but no longer. 

    So if anyone is using Yahoo Instant Messenger on their server and having this problem, this may be your way out. Life is good now that I don't get these calls from the users everyday complaining they are locked up again. 

    • Proposed as answer by Cros.Net Thursday, October 31, 2013 12:55 AM
    Thursday, October 31, 2013 12:50 AM
  • I did have the same issue on Windows 2012 Standard and thank you for saying how.

    I did run a command prompt

    1. sc queryex sens

    2. get the pid number

    3. taskkill /PID (the pid number you got from #1)

    4. net start sens /f

    That works without rebooting the server because I have another things going in process.

    Wednesday, April 02, 2014 7:15 PM
  • I had a user trying to connect as an ICA session to the remote server and was getting hung on SENS.  After reading these posts, I decided to kill all disconnected sessions.  Sure enough, it worked.  

    As I was logging them off, I did notice an account I had recently disabled due to termination being disconnected.  In hindsight, I would have liked to have killed that session alone to see if that was the singular culprit.

    -pete


    Thursday, June 05, 2014 8:17 PM
  • Hey Guys,

    does anyone found the solution from Microsoft... am facing the same issue with Windows 2008 R2 SP1 with Exchange 2010 SP3 running... Hard Reboot works but that's a workaround not the solution... does Microsoft provide any hotfix for this???

    don't have any messenger installed on in (msn, yahoo or lync)... received the Comp+ warning in event viewer he COM+ Event System timed out attempting to fire the Logoff method on event class {D5978650-5B9F-11D1-8DD2-00AA004ABD5E} for publisher  and subscriber .  The subscriber failed to respond within 180 seconds. The display name of the subscription is "Explorer".

    Thanks in advance!



    Prashant


    Saturday, September 27, 2014 7:01 PM