Archiv verlassen und diese Seite im Standarddesign anzeigen : Win 10 - Analyse eines WMI-Errors mittels Logfile
Flyinglosi
2019-12-22, 19:24:36
Hallo,
ich bin seit einigen Monaten beruflich darauf angewiesen das CAD-Programm Solidworks (=SWX) mehrere Stunden täglich zu nutzen. Dieses gönnt sich in Abständen einiger Minuten stets mehrsekündige "Nachdenkpausen", welche die Arbeit auf Dauer recht mühsam machen. Interessanterweise tritt dieses Phänomen auf zwei Workstations von Kollegen ebenfalls auf, wohingegen zwei andere Kollegen davon verschont sind. In meinem Fall handelt es sich übrigens um eine "frische" (3 Wochen alte) WIN10-Installation.
Zuerst dachte ich an reine Performance-Probleme. Allerdings habe ich mit diversen Tweaks bereits alle Register gezogen und mit Ausnahme dieser gelegentlichen Hänger läuft alles wunderbar. Nun habe ich mir mal die Mühe gemacht um ein SWX-internes Logtool genutzt, um der Ursache des Problems auf die Schliche zu kommen. Und siehe da, ein jeder Hänger wird in dem Log-File mit folgender Zeile kommentiert:
<WMIQUERYFAILED>
WMI (=Windows Management Instrumentation) kannte ich nicht. Habt also bitte Verständnis, wenn ich mich hier etwas ungeschickt anstelle. Allerdings bin ich nach kurzer Web-Recherche auf ein Tool von Microsoft mit dem Namen WMIDiag gestolpert und konnte damit ein entsprechendes Logfile erstellen. Und damit zu meiner Frage:
Das mit SWX erstellte Logfile beinhaltet leider keine Zeitstempel. Wie kann ich nun aus dem mittels WMIDiag erstellten Logfile die richtige Fehlermeldung herausfiltern bzw. zuordnen und eventuell sogar rauslesen, was SWX eigentlich anstellen wollte. Ich würde mich diesbezüglich über jeden Tipp freuen.
Danke im Vorhinein für eure Antworten
mfg
Stephan
drdope
2019-12-22, 19:54:19
Schau mal welche Win10-Version konkret auf den betroffenen Workstations läuft... neu aufgesetzt klingt nach "1909".
Win10 ist leider keine sonderlich konkrete Angabe mehr, weil es da zig unterschiedliche Patch-Levels/Version von gibt...
--> https://de.wikipedia.org/wiki/Microsoft_Windows_10#Versionsgeschichte
Ich würde als erstes mal den Support von Solidworks kontaktieren... wenn das Problem mehrere eurer CAD-Workstations betrifft, würde ich mutmaßen, daß der Support es schon auch kennt...
Quasi der Klassiker
-> häufiges tritt häufig auf, seltenes tritt selten auf.
Die Wahrscheinlichkeit, daß das gleiche Phänomen mehrfach (aber nur bei euch) auftritt, ist eher gering.
:)
edit:
"Win10 Solidworks lagging", bringt diverse Google-Hits...
Flyinglosi
2019-12-23, 10:33:20
Danke für deine Antwort.
Es handelt sich um die Version 1903 (Build 18362.387).
Den Support von SWX habe ich in dem Zusammenhang bereits kontaktiert. Damals kam wenig raus. Jetzt wo ich neue Hinweise habe, möchte ich vorab noch selbst möglichst weit recherchieren, damit das ganze nicht wieder im Sand verläuft.
Auch die diversen Hits bei google kenne ich, da ich mich quasi seit Monaten nebenbei mit der Performance von SWX beschäftige.
Gibt es hier eventuell jemanden, der bereits mit WMIDiag gearbeitet hat und weiß, wie man hier einzelne Einträge im Logfile bzw. finalen Statusbericht Prozessen zuordnet?
WMIDiag hilft dir womöglich nicht weiter. Wenn das WMI Repository konsistent ist, wirst du deinen Fehler damit nicht finden.
Schau mal in die Ereignisanzeige unter:
Anwendungs- und Dienstprotokolle\Microsoft\Windows\WMI-Activity\Operational
Dort sollten grundsätzlich fehlgeschlagene WMI-Calls gelistet werden.
(ggfs. vorher mit Rechtsklick "Protokoll aktivieren")
Dann weißt du, weshalb der WMI Query fehlschlägt. Wie du das dann korrigierst, wird dir evtl. der Support sagen können.
Falls dort nichts steht, könntest du auch noch das Tracing (https://docs.microsoft.com/en-us/windows/win32/wmisdk/tracing-wmi-activity) aktivieren. Aber dort werden u.a. alle Aufrufe angezeigt, egal ob erfolgreich oder nicht. Das könnte mühsam werden.
Flyinglosi
2019-12-23, 21:07:59
@Moon: Danke für den Hinweis. Das WMI-Repo hab ich übrigens auf Konsistenz gecheckt. Das passt.
Jeder <WMIQUERYFAILED>-Eintrag im SWX-Log wird in der WMI-Activity mit folgendem Eintrag vermerkt:
ID: {00000000-0000-0000-0000-000000000000};
Clientcomputer: NB-...;
Benutzer: OFFICE\XXX; Clientprozess-ID: 12612;
Komponente: Unknown;
Vorgang: Start IWbemServices::ExecQuery - ROOT\CIMV2 : SELECT * FROM Win32_PerfFormattedData_PerfProc_Process WHERE IDProcess=12612;
Ergebniscode: 0x80041010;
mögliche Ursache: Unknown
Beim Prozess 12612 handelt es sich um Solidworks. Hinter XXX verbirgt sich mein lokaler Benutzer.
Leider hilft mir das selbst nicht weiter, da google dazu nichts passendes ausspuckt. Eventuell hat von euch jemand noch eine Idee, ansonsten werde ich die bisher gewonnen Erkenntnisse zusammenfassen und mich wieder mal an den SWX-Support wenden.
mfg
Stephan
drdope
2019-12-23, 22:44:33
Mal ganz doof gefragt -> kannst du von den fehlerfrei laufenden Workstations mal ein Image erstellen und das auf deine Workstation casten...
Windows-Fehler diagnostizieren und beheben ist immer "Pain in the Ass"...
Und idR den Zeitaufwand nicht wert... wenn man einen besseren PlanB hat.
;)
Wenn das Problem regelmäßig auftritt, könnte es was mit dem Auto-Save zu tun haben. Du könntest in den Einstellungen eine längere frist definieren und du könntest auch prüfen, wohin er sichert. Vielleicht geht die betroffene Festplatte in den Sparmodus und muss für den Auto-Save immer wieder aufgeweckt werden. Vielleicht sind es auch große Saves und langsame Laufwerke/Netzlaufwerke. Prüf das mal.
Flyinglosi
2019-12-24, 08:22:53
Mal ganz doof gefragt -> kannst du von den fehlerfrei laufenden Workstations mal ein Image erstellen und das auf deine Workstation casten...
Windows-Fehler diagnostizieren und beheben ist immer "Pain in the Ass"...
Und idR den Zeitaufwand nicht wert... wenn man einen besseren PlanB hat.
;)
Die letzte Aussage kann ich zu 100% unterschreiben, allerdings sind die vom Fehler verschonten Workstations ansonsten schon ordentlich zugemüllt und ich würde mir wohl nur andere Probleme einfangen. Außerdem ist unser IT-Admin total überlastet und quasi nicht verfügbar. Und ein paar Details eines solchen Vorhabens würden ohne selbigen nicht klappen.
Wenn das Problem regelmäßig auftritt, könnte es was mit dem Auto-Save zu tun haben. Du könntest in den Einstellungen eine längere frist definieren und du könntest auch prüfen, wohin er sichert. Vielleicht geht die betroffene Festplatte in den Sparmodus und muss für den Auto-Save immer wieder aufgeweckt werden. Vielleicht sind es auch große Saves und langsame Laufwerke/Netzlaufwerke. Prüf das mal.
Die Idee hatte ich schon vor einigen Tagen und habe sämtliche entsprechenden Funktionen abgeschaltet.
Zumindest weiss ich nun schonmal, dass diese Hänger nicht einfach auf die Performance der Workstation zurück zu führen sind. Damit kann man zumindest mal ein Dogma aufbrechen, dass stets unsinnig teure Workstations bei uns angeschafft werden. Und eventuell kann der Support mit dieser neuen Info bzgl. WMI ja was anfangen.
Flyinglosi
2020-01-03, 23:04:53
Zusammen mit dem Support konnten wir jetzt ein vermeintliches Problem mit dem .NET-Framework eruieren. Ich hab heute ein wenig im Net gesucht und wurde eher verwirrt. Vielleicht ist allerdings hier jemand vom Fach:
Wie repariert man unter WIN10 das .NET-Framework, bzw. kann man irgendwie eine Neuinstallation durchführen? Letzteres erschiene mir gefühlt sinnvoller.
ReAlDa62
2020-01-03, 23:45:10
Zusammen mit dem Support konnten wir jetzt ein vermeintliches Problem mit dem .NET-Framework eruieren. Ich hab heute ein wenig im Net gesucht und wurde eher verwirrt. Vielleicht ist allerdings hier jemand vom Fach:
Wie repariert man unter WIN10 das .NET-Framework, bzw. kann man irgendwie eine Neuinstallation durchführen? Letzteres erschiene mir gefühlt sinnvoller.
Versuchs mal hiermit: https://support.microsoft.com/de-de/help/2698555/microsoft-net-framework-repair-tool-is-available
Du kannast auch mal schauen, ob ein hotfix/update für eine der nötigen .NET-Framework versionen verfügbar ist, am besten hiermit: AIO-Runtimes (https://www.computerbase.de/downloads/systemtools/all-in-one-runtimes/)
myMind
2020-01-04, 00:49:55
@Moon: Danke für den Hinweis. Das WMI-Repo hab ich übrigens auf Konsistenz gecheckt. Das passt.
Wie hast Du das geprüft? Mit "winmgmt /verifyrepository"? Falls nicht, mach das bitte noch einmal mit Admin-Rechten.
https://docs.microsoft.com/en-us/windows/win32/wmisdk/winmgmt
Jeder <WMIQUERYFAILED>-Eintrag im SWX-Log wird in der WMI-Activity mit folgendem Eintrag vermerkt:
ID: {00000000-0000-0000-0000-000000000000};
Clientcomputer: NB-...;
Benutzer: OFFICE\XXX; Clientprozess-ID: 12612;
Komponente: Unknown;
Vorgang: Start IWbemServices::ExecQuery - ROOT\CIMV2 : SELECT * FROM Win32_PerfFormattedData_PerfProc_Process WHERE IDProcess=12612;
Ergebniscode: 0x80041010;
mögliche Ursache: Unknown
Beim Prozess 12612 handelt es sich um Solidworks. Hinter XXX verbirgt sich mein lokaler Benutzer.
Leider hilft mir das selbst nicht weiter, da google dazu nichts passendes ausspuckt. Eventuell hat von euch jemand noch eine Idee, ansonsten werde ich die bisher gewonnen Erkenntnisse zusammenfassen und mich wieder mal an den SWX-Support wenden.
Die Fehlermeldung 0x80041010 sagt, dass es die Klasse "Win32_PerfFormattedData_PerfProc_Process" nicht gibt. Das würde ich erst einmal prüfen.
Z.B. mit "wbemtest". Einfach oben in der Explorer-Adresszeile so eingeben. Das Tool liegt unter C:\Windows\System32\wbem.
https://docs.microsoft.com/en-us/configmgr/develop/core/understand/introduction-to-wbemtest
- Verbinden
- Klassen aufzählen "Win32_PerfFormattedData"
Handlicher: WMI Explorer von KS-Soft https://www.ks-soft.net/hostmon.eng/downpage.htm
Dann Search > Find... und dort "Win32_PerfFormattedData_PerfProc_Process" eingeben.
Ist die Klasse vorhanden?
WMI Reparatur:
https://www.thewindowsclub.com/how-to-repair-or-rebuild-the-wmi-repository-on-windows-10
.NET Reparatur:
Die "Microsoft .NET Framework ..." haben unter "Programme und Features" jeweils "Reparieren" als Option.
Flyinglosi
2020-01-04, 08:28:37
Danke für eure Tipps, ich habe leider erst am Abend wieder Zeit um diese umzusetzen (melde mich dann wieder).
.NET Reparatur:
Die "Microsoft .NET Framework ..." haben unter "Programme und Features" jeweils "Reparieren" als Option.
Soweit ich das verstanden habe wird das .NET Framework seit einigen Monaten nicht mehr unter „Programme und Features“ aufgelistet, weil es mittels Windows Update verwaltet wird.
myMind
2020-01-04, 12:36:52
Danke für eure Tipps, ich habe leider erst am Abend wieder Zeit um diese umzusetzen (melde mich dann wieder).
Soweit ich das verstanden habe wird das .NET Framework seit einigen Monaten nicht mehr unter „Programme und Features“ aufgelistet, weil es mittels Windows Update verwaltet wird.
Stimmt. Das überrascht mich jetzt. Offenbar werden dort nur die SDKs angezeigt (Multi-Targeting Pack), die man zum Entwickeln benötigt.
Welche .Net Frameworks installiert sind, kriegt man über die Registry heraus:
https://docs.microsoft.com/de-de/dotnet/framework/migration-guide/how-to-determine-which-versions-are-installed
https://stackoverflow.com/questions/3487265/powershell-script-to-return-versions-of-net-framework-on-a-machine/44329052
Folgende Versionen kommen mit Windows:
https://blogs.msdn.microsoft.com/astebner/2007/03/14/mailbag-what-version-of-the-net-framework-is-included-in-what-version-of-the-os/
Da das Framework nun eine Windows-Komponente ist, kann es mit DISM verwaltet werden. Alle installierten Features kann man sich mit DISM anzeigen lassen:
Dism /online /get-features
oder mit der Powershell mit der es sich netter filtern lässt:
Get-WindowsOptionalFeature -Online -FeatureName *NetFx*
Siehe auch Systemsteuerung > Windows-Features aktivieren oder deaktivieren. Dort werden die Pakete auch angezeigt als ".NET Framework..."
Das Paket
Microsoft-Windows-NetFx4-US-OC-Package
ist das 4er Framework.
Entsprechend sollten dann die Reparaturmechanismen über DISM (https://docs.microsoft.com/de-de/windows-hardware/manufacture/desktop/repair-a-windows-image)funktionieren.
Prüfen:
dism /Online /Cleanup-Image /ScanHealth
dism /Online /Cleanup-Image /CheckHealth
Reparieren:
dism /Online /Cleanup-Image /RestoreHealth
Schadet jedenfalls nicht. Aber im Prinzip sollte der WMI-Fehler das tiefer liegende Problem sein.
Flyinglosi
2020-01-04, 19:17:43
Ich fange mal hiermit an (weil es mir aktuell am wichtigsten erscheint):
Wie hast Du das geprüft? Mit "winmgmt /verifyrepository"? Falls nicht, mach das bitte noch einmal mit Admin-Rechten.
Habe ich gerade nochmal wiederholt. Spuckt die Meldung "Das WMI-Repository ist konsistent." aus.
Die Fehlermeldung 0x80041010 sagt, dass es die Klasse "Win32_PerfFormattedData_PerfProc_Process" nicht gibt. Das würde ich erst einmal prüfen.
Z.B. mit "wbemtest". Einfach oben in der Explorer-Adresszeile so eingeben. Das Tool liegt unter C:\Windows\System32\wbem.
https://docs.microsoft.com/en-us/configmgr/develop/core/understand/introduction-to-wbemtest
- Verbinden
- Klassen aufzählen "Win32_PerfFormattedData"
Handlicher: WMI Explorer von KS-Soft https://www.ks-soft.net/hostmon.eng/downpage.htm
Dann Search > Find... und dort "Win32_PerfFormattedData_PerfProc_Process" eingeben.
Ist die Klasse vorhanden?
WMI Reparatur:
https://www.thewindowsclub.com/how-to-repair-or-rebuild-the-wmi-repository-on-windows-10
Ich habe beide Methoden genutzt und die Klasse scheint nicht vorhanden zu sein. Nun stehe ich aber auf der Leitung, denn die von dir verlinkte Anleitung bzgl. Reparatur würde ja ein Repo voraussetzen, welches beim Check mittels "winmgmt" als fehlerhaft eingestuft wurde, oder liege ich hier falsch.
Danke im Vorhinein für die weitere Unterstützung.
mfg
Stephan
Flyinglosi
2020-01-04, 20:49:46
Der Vollständigkeit wegen: Ein Reset des Repos mittels "winmgmt /resetrepository" hat das Problem nicht gelöst.
Probier mal wie hier beschrieben:
https://javalins.wordpress.com/2013/10/21/missing-wmi-perfformatteddata-counters/
Winmgmt /resyncperf
Anschließend Windows Management Service neu starten:
Net stop winmgmt /y
Net start winmgmt
myMind
2020-01-04, 22:41:30
Der Vollständigkeit wegen: Ein Reset des Repos mittels "winmgmt /resetrepository" hat das Problem nicht gelöst.
Kannst Du mal einen Screenshot vom WMI Explorer machen, wo man die Classes sieht. So ab "Win32_PCMICIAController". Danach folgt bei mir "Win32_PerfFormattedData", "Win32_PerfFormattedData...", "Win32_PerfRawData" und alle weiteren Performance Counter. Danach geht es mit "Win32_PhysicalMedia" weiter. Fehlen bei dir genau die "Win32_Perf*Data" Einträge? Hat der Vorschlag von MooN geholfen sie neu hervorzurufen?
Der Parameter "/resetrepository" baut nach meinem Verständnis das WMI Repository aus den MOF Dateien neu auf. Dazu werden alle MOF-Dateien verwendet die in der Registry unter
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Wbem\CIMOM\Autorecover MOFs
registriert sind (im Regedit doppelklicken). Da sind bei mir unter anderem auch folgende Dateien vermerkt:
...
%windir%\system32\wbem\wmiperfclass.mof
%windir%\system32\wbem\wmiperfinst.mof
...
https://docs.microsoft.com/en-us/windows/win32/wmisdk/wmi-providers
Die beiden Dateien sind bei mir vorhanden und enthalten C-Code. Die Class-IDs verweisen auf
C:\Windows\System32\wbem\WmiPerfClass.dll
C:\Windows\System32\wbem\WmiPerfInst.dll
Über diesen Mechanismus wird das Repository in C:\Windows\System32\wbem\Repository aus den DLLs neu erzeugt.
Aus irgendeinem Grunde, werden die oben genannten DLLs nicht gefunden - weil sie gar nicht registriert sind - oder können nicht geladen werden.
Mit dem Wissen kann man das WMIDiag Tool (ein VBS Script) benutzen:
https://www.microsoft.com/en-us/download/details.aspx?id=7684
In %temp% wird eine lange WMIDIAG-V2.2_....LOG und eine kurze WMIDIAG-V2.2_...REPORT.TXT Datei erzeugt. Nicht davon verunsichern lassen, dass dort überhaupt Fehler drin sind. Das dürfte auf quasi jedem System der Fall sein.
In der LOG Datei sollte sich die korrekte Registrierung der WMIPERF DLLs finden:
.1150 23:08:26 (4) Reading registry (REG_SZ) 'HKCR\CLSID\{661FF7F6-F4D1-4593-B59D-4C54C1ECE68B}\InProcServer32\'.
.1151 23:08:26 (3) 'C:\WINDOWS\SYSTEM32\WBEM\WMIPERFCLASS.DLL' registered correctly (\CLSID\{661FF7F6-F4D1-4593-B59D-4C54C1ECE68B}\InProcServer32).
.1152 23:08:26 (4) Reading registry (REG_SZ) 'HKCR\CLSID\{CA2AF3B4-C15E-412B-B453-557746675FB7}\InProcServer32\'.
.1153 23:08:26 (3) 'C:\WINDOWS\SYSTEM32\WBEM\WMIPERFINST.DLL' registered correctly (\CLSID\{CA2AF3B4-C15E-412B-B453-557746675FB7}\InProcServer32).
Falls Du es nicht sowieso schon gemacht hast, lass bitte ein
sfc /scannow
laufen, um sicherzustellen, dass die Dateien deiner Windowsinstallation OK sind.
Flyinglosi
2020-01-05, 13:36:56
Kannst Du mal einen Screenshot vom WMI Explorer machen, wo man die Classes sieht. So ab "Win32_PCMICIAController". Danach folgt bei mir "Win32_PerfFormattedData", "Win32_PerfFormattedData...", "Win32_PerfRawData" und alle weiteren Performance Counter. Danach geht es mit "Win32_PhysicalMedia" weiter. Fehlen bei dir genau die "Win32_Perf*Data" Einträge?
Siehe Anhang. Sofern ich das beurteilen kann, fehlt eben genau die in der Fehlermeldung angeführte (Unter-)Klasse
Hat der Vorschlag von MooN geholfen sie neu hervorzurufen?
Hat leider nichts gebracht
Der Parameter "/resetrepository" baut nach meinem Verständnis das WMI Repository aus den MOF Dateien neu auf. Dazu werden alle MOF-Dateien verwendet die in der Registry unter
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Wbem\CIMOM\Autorecover MOFs
registriert sind (im Regedit doppelklicken). Da sind bei mir unter anderem auch folgende Dateien vermerkt:
...
%windir%\system32\wbem\wmiperfclass.mof
%windir%\system32\wbem\wmiperfinst.mof
...
Ja das ist bei mir auch so eingetragen.
https://docs.microsoft.com/en-us/windows/win32/wmisdk/wmi-providers
Die beiden Dateien sind bei mir vorhanden und enthalten C-Code. Die Class-IDs verweisen auf
C:\Windows\System32\wbem\WmiPerfClass.dll
C:\Windows\System32\wbem\WmiPerfInst.dll
In den MOF-Files steht bei mir folgendes:
instance of __Win32Provider as $P
{
Name = "WmiPerfClass";
ClsId = "{661FF7F6-F4D1-4593-B59D-4C54C1ECE68B}";
UnloadTimeout = "00000000001500.000000:000";
HostingModel = "LocalSystemHost";
Version = 3;
};
und
instance of __Win32Provider as $P
{
Name = "WmiPerfInst";
ClsId = "{CA2AF3B4-C15E-412B-B453-557746675FB7}";
ClientLoadableCLSID = "{FCF7A6F2-3300-4386-9A4F-0DD4E3226507}";
HostingModel = "LocalServiceHost";
};
Die ClsId verweisen laut Registry allerdings auf
C:\Windows\SysWOW64\wbem\WmiPerfClass.dll
C:\Windows\SysWOW64\wbem\WmiPerfInst.dll
Also die 64er Varianten. Ist das relevant? Und ist der Eintrag neben "ClientLoadableCLSID" auch relevant (anderer Schlüssel mit identem Pfad)
Über diesen Mechanismus wird das Repository in C:\Windows\System32\wbem\Repository aus den DLLs neu erzeugt.
Aus irgendeinem Grunde, werden die oben genannten DLLs nicht gefunden - weil sie gar nicht registriert sind - oder können nicht geladen werden.
Mit dem Wissen kann man das WMIDiag Tool (ein VBS Script) benutzen:
https://www.microsoft.com/en-us/download/details.aspx?id=7684
In %temp% wird eine lange WMIDIAG-V2.2_....LOG und eine kurze WMIDIAG-V2.2_...REPORT.TXT Datei erzeugt. Nicht davon verunsichern lassen, dass dort überhaupt Fehler drin sind. Das dürfte auf quasi jedem System der Fall sein.
In der LOG Datei sollte sich die korrekte Registrierung der WMIPERF DLLs finden:
.1150 23:08:26 (4) Reading registry (REG_SZ) 'HKCR\CLSID\{661FF7F6-F4D1-4593-B59D-4C54C1ECE68B}\InProcServer32\'.
.1151 23:08:26 (3) 'C:\WINDOWS\SYSTEM32\WBEM\WMIPERFCLASS.DLL' registered correctly (\CLSID\{661FF7F6-F4D1-4593-B59D-4C54C1ECE68B}\InProcServer32).
.1152 23:08:26 (4) Reading registry (REG_SZ) 'HKCR\CLSID\{CA2AF3B4-C15E-412B-B453-557746675FB7}\InProcServer32\'.
.1153 23:08:26 (3) 'C:\WINDOWS\SYSTEM32\WBEM\WMIPERFINST.DLL' registered correctly (\CLSID\{CA2AF3B4-C15E-412B-B453-557746675FB7}\InProcServer32).
Hier fiel mir auf, dass bei mir zwei Einträge bzgl. "WMIPERFINST" aufgelistet werden:
.1271 13:06:48 (3) 'C:\WINDOWS\SYSTEM32\WBEM\WMIPERFCLASS.DLL' registered correctly (\CLSID\{661FF7F6-F4D1-4593-B59D-4C54C1ECE68B}\InProcServer32).
.1272 13:06:48 (4) Reading registry (REG_SZ) 'HKCR\CLSID\{CA2AF3B4-C15E-412B-B453-557746675FB7}\InProcServer32\'.
.1273 13:06:48 (3) 'C:\WINDOWS\SYSTEM32\WBEM\WMIPERFINST.DLL' registered correctly (\CLSID\{CA2AF3B4-C15E-412B-B453-557746675FB7}\InProcServer32).
.1274 13:06:48 (4) Reading registry (REG_SZ) 'HKCR\CLSID\{FCF7A6F2-3300-4386-9A4F-0DD4E3226507}\InProcServer32\'.
.1275 13:06:48 (3) 'C:\WINDOWS\SYSTEM32\WBEM\WMIPERFINST.DLL' registered correctly (\CLSID\{FCF7A6F2-3300-4386-9A4F-0DD4E3226507}\InProcServer32).
Falls Du es nicht sowieso schon gemacht hast, lass bitte ein
sfc /scannow
laufen, um sicherzustellen, dass die Dateien deiner Windowsinstallation OK sind.
Hatte ich bereits (desöfteren) gemacht.
mfg
Stephan
myMind
2020-01-05, 14:34:42
Siehe Anhang. Sofern ich das beurteilen kann, fehlt eben genau die in der Fehlermeldung angeführte (Unter-)Klasse
Den Anhang kann ich im Posting nicht sehen.
Hat leider nichts gebracht
:(
Die ClsId verweisen laut Registry allerdings auf
C:\Windows\SysWOW64\wbem\WmiPerfClass.dll
C:\Windows\SysWOW64\wbem\WmiPerfInst.dll
Also die 64er Varianten. Ist das relevant? Und ist der Eintrag neben "ClientLoadableCLSID" auch relevant (anderer Schlüssel mit identem Pfad)
Die CLSIDs gibt es zweimal in der Registry.
Die von dir genannten Einträge sind unterhalb von
Computer\HKEY_CLASSES_ROOT\Wow6432Node\CLSID\
Das sind die 32-Bit Libraries (SysWOW64).
Hier
Computer\HKEY_CLASSES_ROOT\CLSID\
sind die 64-bit Libraries (system32).
Du siehst im Log, dass die richtigen - die 64-bit Dateien in system32 - registriert werden. Also das sieht soweit alles gut aus.
Hier fiel mir auf, dass bei mir zwei Einträge bzgl. "WMIPERFINST" aufgelistet werden:
Passt auch. Ist bei mir exakt so. Die beiden letzten Log-Einträge hatte ich nur nicht gepostet.
myMind
2020-01-05, 15:24:48
Die Classes:
Win32_PerfFormattedData_Perf*
Win32_PerfFormattedData_NET*
fehlen.
Es gibt zwei Lademechanismen die der WMIPerfClass Provider realisiert:
https://docs.microsoft.com/de-de/windows/win32/wmisdk/performance-libraries-and-wmi
Auf den ersten Blick sieht es für mich so aus, als ob der "version 1" Mechanismus nicht funktioniert. Also wenn du auf
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
in der Registry gehst und nach "Performance" Schlüssel suchst, findest Du alle Services, die Performancecounter bereitstellen. Unter anderem auch den Service "PerfProc". Aber aus irgendeinem Grunde werden dessen Counter nicht erzeugt. Dies sollte "WMIPerfClass Provider creates WMI Performance Counter Classes at system initialization." passieren.
Flyinglosi
2020-01-05, 18:45:41
Heureka, Danke für den finalen Tipp!!!
Dieser hat mich zu folgendem Link geführt, und da ich ohnehin ein Systemimage habe, wars mir den Versuch wert:
https://support.microsoft.com/en-us/help/2554336/how-to-manually-rebuild-performance-counters-for-windows-server-2008-6
Und Siehe da, plötzlich sind im WMI_Explorer neue Klassen aufgetaucht ;)
Ich teste jetzt mal ein wenig rum ob das Thema nun erledigt ist, aber auf den ersten Blick sieht alles gut aus.
Wo darf ich denn die "Dankesbierkiste" hinschicken?
myMind
2020-01-05, 21:38:46
Heureka, Danke für den finalen Tipp!!!
Dieser hat mich zu folgendem Link geführt, und da ich ohnehin ein Systemimage habe, wars mir den Versuch wert:
https://support.microsoft.com/en-us/help/2554336/how-to-manually-rebuild-performance-counters-for-windows-server-2008-6
Und Siehe da, plötzlich sind im WMI_Explorer neue Klassen aufgetaucht ;)
Ich teste jetzt mal ein wenig rum ob das Thema nun erledigt ist, aber auf den ersten Blick sieht alles gut aus.
Ja wie cool ist das denn. Super! Hoffentlich löst das auch das Ursprungsproblem. Ich drücke die Daumen.
Wo darf ich denn die "Dankesbierkiste" hinschicken?
Freut mich das ich helfen konnte.
Flyinglosi
2020-01-06, 21:16:39
Nach ein paar Stunden Arbeit mit Solidworks kann ich nun sagen, dass die WMI-Errors nicht mehr auftreten. Das heißt leider nicht, dass sich nicht noch immer gelegentlich ein Hänger einschleicht, allerdings hat sich deren Häufigkeit drastisch reduziert.
Mir fehlt aber grad die Idee, was die immer noch vereinzelt auftretenden Nachdenkpausen auslöst. Daher verbuche ich das Erreichte als Erfolg und freue mich darüber.
Freut mich das ich helfen konnte.
Tausend Dank nochmal. Wenn ich mich irgendwie revanchieren kann (das Angebot mit der Bierkiste steht, musst mir nur deine Adresse per PM nennen und ich bestell dir eine über Amazon ;)) sag Bescheid.
myMind
2020-01-07, 00:18:36
Nach ein paar Stunden Arbeit mit Solidworks kann ich nun sagen, dass die WMI-Errors nicht mehr auftreten. Das heißt leider nicht, dass sich nicht noch immer gelegentlich ein Hänger einschleicht, allerdings hat sich deren Häufigkeit drastisch reduziert.
Mir fehlt aber grad die Idee, was die immer noch vereinzelt auftretenden Nachdenkpausen auslöst. Daher verbuche ich das Erreichte als Erfolg und freue mich darüber.
:cool:
Tausend Dank nochmal. Wenn ich mich irgendwie revanchieren kann (das Angebot mit der Bierkiste steht, musst mir nur deine Adresse per PM nennen und ich bestell dir eine über Amazon ;)) sag Bescheid.
Feiner Zug. Danke für das Angebot. Aber passt für mich schon so.
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.