Homeserver Forum

Die Anlaufstelle für alle Windows Home Server Administratoren und Anwender
https://forum.home-server-blog.de/

WHS2011, LiveMesh und die Serverdienste

https://forum.home-server-blog.de/viewtopic.php?t=18286

Seite 1 von 1

WHS2011, LiveMesh und die Serverdienste

Verfasst: 11. Aug 2012, 08:57
von jsysde
Moin Gemeinde,

gestern abend bemerkte ich, dass die Meldungsanzeige im Dashboard veraltete, weil längste erledigte Warnungen anzeigte. Ein Klick auf "Aktualisieren" führte dazu, dass ich nur "Keine Daten verfügbar" zu Gesicht bekam. Einige Zeit später tauchten wieder die gleichen, alten Warnungen auf. Was war passiert?

Ein Blick ins Eventlog zeigte eine abstürzende .NET-Applikation, in den Details des Fehlertextes entdeckte ich dann Verweise auf eine fehlende .dll-Datei in C:\Program Files\Common Files\Microsoft Shared\Windows Live. Ausserdem stoppten der Integritäts- und der Domänennamenverwaltungsdienst. WTF?

Ich hatte vor Urzeiten mal LiveMesh aus den Windows Live Essentials 2011 auf dem WHS2011 installiert und auch konfiguriert. Nach der Ankündigung von Microsoft, LiveMesh zu streichen und stattdessen SkyDrive zu nutzen, dachte ich mir: Gut, du nutzt LiveMesh nicht mehr, dann kannst du es ja auch deinstallieren. Gesagt, getan - der Anfang vom Übel, seit dem traten diese Fehler auf.

Also LiveMesh wieder rauf und aktiviert, siehe da, Meldungsanzeige ist wieder aktuell und lässt sich auch wieder "Aktualisieren". Warum sich LiveMesh so tief ins System gräbt, keine Ahnung. Die De-Installation war eigentlich sauber durchgelaufen. Mittlerweile ist LiveMesh also installiert und konfiguriert und hat auch einmal brav synchronisiert. Da ich es wie gesagt nicht mehr benötige, habe ich es aus dem Autostart (msconfig) herausgenommen, der Server läuft dennoch sauber. Es geht also nur um die .dll-Datei, die wohl vorhanden sein muss.

Anyway, dies nur als erster Hinweis, falls ausser mir noch jemand die Schnapsidee hatte, LiveMesh auf dem WHS2011 zu betreiben. Ich werde noch Screenshots und Beschreibungen der Fehler nachreichen, bin grad zeitlich etwas knapp. Dummerweise sind bei meinen Fehlersuch- und Aufräumaktionen auch sämtliche LightsOut-Aufzeichnungen verlorengegangen, im Laufzeitdiagramm taucht der Server erst wieder seit gestern abend, als der der Fehler behoben war.

Nochmal der Hinweis: Falls ihr LiveMesh installiert habt, de-installiert es bloss nicht!

Cheers,
jsysde

Re: WHS2011, LiveMesh und die Serverdienste

Verfasst: 11. Aug 2012, 15:30
von raedwulf76
merci, jetzt weiß ich, warum meiner nicht mehr sauber läuft. Werd gleich mal Live-Mesh wieder installieren.

Re: WHS2011, LiveMesh und die Serverdienste

Verfasst: 12. Aug 2012, 10:19
von jsysde
So, wie versprochen reiche ich noch ein paar Infos nach.
Durch die De-Installation von LiveMesh tauchen im Eventlog des Servers folgende Fehlermeldungen auf:
Fehlermeldungen .NET
Fehlermeldungen .NET
whserror.png (3.54 KiB) 1183 mal betrachtet
Ausführlicher Text der ersten (untersten) Fehlermeldung:

Code: Alles auswählen

Protokollname: Application
Quelle:        .NET Runtime
Datum:         10.08.2012 20:21:18
Ereignis-ID:   1025
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      <SERVERNAME>
Beschreibung:
Anwendung: SharedServiceHost.exe
Frameworkversion: v4.0.30319
Beschreibung: Die Anwendung forderte die Beendigung des Prozesses durch System.Environment.FailFast(Zeichenfolgenmeldung) an.
Meldung: Unhandled exception from operation:

Service type: Microsoft.WindowsServerSolutions.RemoteAccess.Domains.DomainProviderManager
Operation: [http://tempuri.org/] IDomainMaintenanceManager.ValidateCredentials
Async: False
Parameters: 


System.IO.FileNotFoundException: Could not load msidcrl40.dll from C:\Program Files\Common Files\Microsoft Shared\Windows Live\msidcrl40.dll
   bei Microsoft.WindowsServerSolutions.Identity.WindowsLive.ManagedIDCRL.Initialize(String proxy, Int32 version)
   bei Microsoft.WindowsServerSolutions.RemoteAccess.Domains.WindowsLiveProviderBase.GetLiveRpsToken(DomainProviderCredentials credentials)
   bei Microsoft.WindowsServerSolutions.RemoteAccess.Domains.WindowsLiveProviderBase.ValidateCredentials()
   bei Microsoft.WindowsServerSolutions.RemoteAccess.Domains.DomainProviderManager.ValidateCredentials()
   bei SyncInvokeValidateCredentials(Object , Object[] , Object[] )
   bei System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs)
   bei Microsoft.WindowsServerSolutions.Common.ProviderFramework.Internal.ExceptionScreener._ScreenForExceptions(GeneralInvoker invokeMe, Object instance, Object[] inputs, Object[]& outputs)
Stapel:
   bei System.Environment.FailFast(System.String, System.Exception)
   bei Microsoft.WindowsServerSolutions.Common.ProviderFramework.Internal.ExceptionScreener._ScreenForExceptions(GeneralInvoker, System.Object, System.Object[], System.Object[] ByRef)
   bei Microsoft.WindowsServerSolutions.Common.ProviderFramework.Internal.ExceptionScreener.Invoke(System.Object, System.Object[], System.Object[] ByRef)
   bei System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(System.ServiceModel.Dispatcher.MessageRpc ByRef)
   bei System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(System.ServiceModel.Dispatcher.MessageRpc ByRef)
   bei System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage31(System.ServiceModel.Dispatcher.MessageRpc ByRef)
   bei System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean)
   bei System.ServiceModel.Dispatcher.ChannelHandler.DispatchAndReleasePump(System.ServiceModel.Channels.RequestContext, Boolean, System.ServiceModel.OperationContext)
   bei System.ServiceModel.Dispatcher.ChannelHandler.HandleRequest(System.ServiceModel.Channels.RequestContext, System.ServiceModel.OperationContext)
   bei System.ServiceModel.Dispatcher.ChannelHandler.AsyncMessagePump(System.IAsyncResult)
   bei System.Runtime.Fx+AsyncThunk.UnhandledExceptionFrame(System.IAsyncResult)
   bei Microsoft.WindowsServerSolutions.Common.ProviderFramework.Internal.AsyncResult`1[[Microsoft.WindowsServerSolutions.Common.ProviderFramework.Internal.InputChannelRequeuer`1+TryReceiveResult[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]], Sku, Version=6.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]].Complete(Boolean, System.Func`1<TryReceiveResult<System.__Canon>>)
   bei Microsoft.WindowsServerSolutions.Common.ProviderFramework.Internal.CoalescingAsyncResult`1[[Microsoft.WindowsServerSolutions.Common.ProviderFramework.Internal.InputChannelRequeuer`1+TryReceiveResult[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]], Sku, Version=6.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]._MyCallback(System.IAsyncResult)
   bei System.Runtime.AsyncResult.Complete(Boolean)
   bei System.ServiceModel.Channels.FramingDuplexSessionChannel+TryReceiveAsyncResult.OnReceive(System.IAsyncResult)
   bei System.Runtime.Fx+AsyncThunk.UnhandledExceptionFrame(System.IAsyncResult)
   bei System.Runtime.AsyncResult.Complete(Boolean)
   bei System.ServiceModel.Channels.SynchronizedMessageSource+ReceiveAsyncResult.OnReceiveComplete(System.Object)
   bei System.ServiceModel.Channels.SessionConnectionReader.OnAsyncReadComplete(System.Object)
   bei System.Runtime.Fx+AsyncThunk.UnhandledExceptionFrame(System.IAsyncResult)
   bei System.Net.LazyAsyncResult.Complete(IntPtr)
   bei System.Net.Security.NegotiateStream.ProcessFrameBody(Int32, Byte[], Int32, Int32, System.Net.AsyncProtocolRequest)
   bei System.Net.Security.NegotiateStream.ReadCallback(System.Net.AsyncProtocolRequest)
   bei System.Net.FixedSizeReader.CheckCompletionBeforeNextRead(Int32)
   bei System.Net.FixedSizeReader.ReadCallback(System.IAsyncResult)
   bei System.Runtime.AsyncResult.Complete(Boolean)
   bei System.ServiceModel.Channels.ConnectionStream+ReadAsyncResult.OnAsyncReadComplete(System.Object)
   bei System.ServiceModel.Channels.SocketConnection.AsyncReadCallback(Boolean, Int32, Int32)
   bei System.Runtime.Fx+IOCompletionThunk.UnhandledExceptionFrame(UInt32, UInt32, System.Threading.NativeOverlapped*)
   bei System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32, UInt32, System.Threading.NativeOverlapped*)

Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name=".NET Runtime" />
    <EventID Qualifiers="0">1025</EventID>
    <Level>2</Level>
    <Task>0</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2012-08-10T18:21:18.000000000Z" />
    <EventRecordID>107511</EventRecordID>
    <Channel>Application</Channel>
    <Computer>SERVERNAME</Computer>
    <Security />
  </System>
  <EventData>
    <Data>Anwendung: SharedServiceHost.exe
Frameworkversion: v4.0.30319
Beschreibung: Die Anwendung forderte die Beendigung des Prozesses durch System.Environment.FailFast(Zeichenfolgenmeldung) an.
Meldung: Unhandled exception from operation:

Service type: Microsoft.WindowsServerSolutions.RemoteAccess.Domains.DomainProviderManager
Operation: [http://tempuri.org/] IDomainMaintenanceManager.ValidateCredentials
Async: False
Parameters: 


System.IO.FileNotFoundException: Could not load msidcrl40.dll from C:\Program Files\Common Files\Microsoft Shared\Windows Live\msidcrl40.dll
   bei Microsoft.WindowsServerSolutions.Identity.WindowsLive.ManagedIDCRL.Initialize(String proxy, Int32 version)
   bei Microsoft.WindowsServerSolutions.RemoteAccess.Domains.WindowsLiveProviderBase.GetLiveRpsToken(DomainProviderCredentials credentials)
   bei Microsoft.WindowsServerSolutions.RemoteAccess.Domains.WindowsLiveProviderBase.ValidateCredentials()
   bei Microsoft.WindowsServerSolutions.RemoteAccess.Domains.DomainProviderManager.ValidateCredentials()
   bei SyncInvokeValidateCredentials(Object , Object[] , Object[] )
   bei System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs)
   bei Microsoft.WindowsServerSolutions.Common.ProviderFramework.Internal.ExceptionScreener._ScreenForExceptions(GeneralInvoker invokeMe, Object instance, Object[] inputs, Object[]& outputs)
Stapel:
   bei System.Environment.FailFast(System.String, System.Exception)
   bei Microsoft.WindowsServerSolutions.Common.ProviderFramework.Internal.ExceptionScreener._ScreenForExceptions(GeneralInvoker, System.Object, System.Object[], System.Object[] ByRef)
   bei Microsoft.WindowsServerSolutions.Common.ProviderFramework.Internal.ExceptionScreener.Invoke(System.Object, System.Object[], System.Object[] ByRef)
   bei System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(System.ServiceModel.Dispatcher.MessageRpc ByRef)
   bei System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(System.ServiceModel.Dispatcher.MessageRpc ByRef)
   bei System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage31(System.ServiceModel.Dispatcher.MessageRpc ByRef)
   bei System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean)
   bei System.ServiceModel.Dispatcher.ChannelHandler.DispatchAndReleasePump(System.ServiceModel.Channels.RequestContext, Boolean, System.ServiceModel.OperationContext)
   bei System.ServiceModel.Dispatcher.ChannelHandler.HandleRequest(System.ServiceModel.Channels.RequestContext, System.ServiceModel.OperationContext)
   bei System.ServiceModel.Dispatcher.ChannelHandler.AsyncMessagePump(System.IAsyncResult)
   bei System.Runtime.Fx+AsyncThunk.UnhandledExceptionFrame(System.IAsyncResult)
   bei Microsoft.WindowsServerSolutions.Common.ProviderFramework.Internal.AsyncResult`1[[Microsoft.WindowsServerSolutions.Common.ProviderFramework.Internal.InputChannelRequeuer`1+TryReceiveResult[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]], Sku, Version=6.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]].Complete(Boolean, System.Func`1<TryReceiveResult<System.__Canon>>)
   bei Microsoft.WindowsServerSolutions.Common.ProviderFramework.Internal.CoalescingAsyncResult`1[[Microsoft.WindowsServerSolutions.Common.ProviderFramework.Internal.InputChannelRequeuer`1+TryReceiveResult[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]], Sku, Version=6.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]._MyCallback(System.IAsyncResult)
   bei System.Runtime.AsyncResult.Complete(Boolean)
   bei System.ServiceModel.Channels.FramingDuplexSessionChannel+TryReceiveAsyncResult.OnReceive(System.IAsyncResult)
   bei System.Runtime.Fx+AsyncThunk.UnhandledExceptionFrame(System.IAsyncResult)
   bei System.Runtime.AsyncResult.Complete(Boolean)
   bei System.ServiceModel.Channels.SynchronizedMessageSource+ReceiveAsyncResult.OnReceiveComplete(System.Object)
   bei System.ServiceModel.Channels.SessionConnectionReader.OnAsyncReadComplete(System.Object)
   bei System.Runtime.Fx+AsyncThunk.UnhandledExceptionFrame(System.IAsyncResult)
   bei System.Net.LazyAsyncResult.Complete(IntPtr)
   bei System.Net.Security.NegotiateStream.ProcessFrameBody(Int32, Byte[], Int32, Int32, System.Net.AsyncProtocolRequest)
   bei System.Net.Security.NegotiateStream.ReadCallback(System.Net.AsyncProtocolRequest)
   bei System.Net.FixedSizeReader.CheckCompletionBeforeNextRead(Int32)
   bei System.Net.FixedSizeReader.ReadCallback(System.IAsyncResult)
   bei System.Runtime.AsyncResult.Complete(Boolean)
   bei System.ServiceModel.Channels.ConnectionStream+ReadAsyncResult.OnAsyncReadComplete(System.Object)
   bei System.ServiceModel.Channels.SocketConnection.AsyncReadCallback(Boolean, Int32, Int32)
   bei System.Runtime.Fx+IOCompletionThunk.UnhandledExceptionFrame(UInt32, UInt32, System.Threading.NativeOverlapped*)
   bei System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32, UInt32, System.Threading.NativeOverlapped*)
</Data>
  </EventData>
</Event>
Es wird also versucht, auf die fehlende Datei msidcrl40.dll zuzugreifen, die wohl bei der De-Insatllation von LiveMesh gelöscht wurde.

Das führt dann dazu, dass die folgenden zwei Serverdienste abschmieren:
- Integritätsdienst von Windows Server
- Windows Server-Domänennamenverwaltung

Zwar starten die Dienste automatisch neu, allerdings nur ingesamt drei mal. Da der Fehler aber periodisch immer wieder auftritt (auch ohne in der Meldungsanzeige auf "Aktualisieren" zu klicken), laufen die Dienste also irgendwann gar nicht mehr. Und das hat Auswirkungen, von einer falschen Meldungsanzeige mal abgesehen funktionieren weder Client- noch Serverbackup, da beide ja unmittelbar ihre Fehler an die Meldungsanzeige schicken. Weiterhin beeinflussen die Dienste die Funktionalität von LightsOut, da LO nicht mehr mitbekommt, wenn ein Rechner ausgeschaltet wird. So lief mein Server dann eine ganze Nacht durch, weil das Laptop meiner Frau noch als "Online" vermeldet war. Der Server verschwindet vollständig aus dem Laufzeitdiagramm von LO.
Laufzeitdiagramm LO
Laufzeitdiagramm LO
whslaufzeit.png (36 KiB) 1183 mal betrachtet
Die Fehlermeldung lässt eindeutig erkenne, das LiveMesh hier der Übeltäter ist. Ich hatte nun im ersten Step versucht, durch Entfernen der "Windows Live"-Einträge in der Registry das Problem zu beseitigen, was leider nicht funktioniert hat. Wahrscheinlich ist dieser Registry-Eingriff der Grund dafür, dass LO unter "Energieeinsparung" alle Werte gelöscht und erst mit Beseitigung des Fehlers durch Neu-Installation von Live-Mesh wieder angefangen hat, die Laufzeit des Servers zu protokollieren. Statt einer Auswertung der letzten gut 365 Tage (so lange läuft LO bei mir eigentlich schon), werden nun nur zwei Tage angezeigt. Verschmerzbar, aber ärgerlich.

Erst nach diesem fehlgeschlagenen Versuch habe ich LiveMesh dann neu installiert und es vorerst _nicht!_ gestartet. Ein Klick auf "Aktualisieren" in der Meldungsanzeige führte aber zum gleichen Ergebnis: Zwei abgeschmierte Dienste und keine brauchbare Anzeige. Lediglich die Fehlermeldung von .NET änderte sich von "Datei nicht gefunden" in "Einstiegspunkt in DLL nicht gefunden". Erst nachdem ich LiveMesh gestartet, konfiguriert und einmal synchronisiert habe, waren die Fehlermeldungen verschwunden und der Server läuft wieder rund. Vorübergehend habe ich den automatischen Start von LiveMesh per msconfig verhindert:
msconfig
msconfig
msconfig.png (42.99 KiB) 1183 mal betrachtet
Mittlerweile habe ich google gequält, konnte aber keinerlei Hinweise darauf finden, warum und vor allem wo genau sich LiveMesh so tief ins System gräbt und wie man diese ungewollte Abhängigkeit wieder aufheben könnte. Über kurz oder lang hätte ich LiveMesh jedenfalls gern vom System runter. Sachdienliche Hinweise werden dankend entgegengenommen. ;-)

Cheers,
jsysde
Alle Zeiten sind UTC+02:00
Seite 1 von 1

Powered by phpBB® Forum Software © phpBB Limited

Deutsche Übersetzung durch phpBB.de