Laden...

Das Programm wurde mit Code 3221226356 (0xc0000374) beendet.

Erstellt von LittleTester vor einem Jahr Letzter Beitrag vor einem Jahr 1.154 Views
L
LittleTester Themenstarter:in
158 Beiträge seit 2019
vor einem Jahr
Das Programm wurde mit Code 3221226356 (0xc0000374) beendet.

Mein C# Programm funktioniert auf meinem Rechner zu Hause, aber im Geschäft wird die Anwendung in VS mit folgendem Fehler beendet:

Das Programm "[16224] SysteminventoryV2.exe" wurde mit Code 3221226356 (0xc0000374) beendet.

Ursächlich dafür ist folgender Code:


// Use WindowsAPICodePack.
public static string GetSystemEnergyState()
{
    string SystemEnergyState = PowerManager.PowerPersonality.ToString();
    return SystemEnergyState;
}

lblSystemEnergyState.Text = SystemClass.GetSystemEnergyState(); // Wenn auskommentiert startet das Programm, bzw. bleibt offen

Wenn man Google bemüht finden sich Fehler in Bezug auf C++, zu C# eher weniger und nichts was mir weiterhelfen würde. Rechner wurde bereits neu gestartet. Fehler 0xc0000374 sieht für mich nach einem speicherproblem aus, aber stimmt das überhaupt und wenn ja, wieso?

Ich verwende das WindowsAPICodePack 7.0.1
https://www.nuget.org/packages/WindowsAPICodePack/7.0.1

IDE: Visual Studio 2022
Sofern nicht anders genannt basieren meine Projekte auf C# und .net 6

4.931 Beiträge seit 2008
vor einem Jahr

Der Fehlercode steht für STATUS_HEAP_CORRUPTION, d.h. wie du richtig erkannt hast, ein internes Speicherproblem (meistens aufgrund einer doppelten Speicherfreigabe).
Du kannst mal in der Ereignisanzeige schauen, ob noch mehr für diesen Absturz protokolliert wurde (z.B. der Name der DLL).
Und überprüfe mal, ob die Powermanagement-Treiber (vom Hersteller des Rechners) aktuell sind.

L
LittleTester Themenstarter:in
158 Beiträge seit 2019
vor einem Jahr

Danke.
Ich habe das Tool gerade bei meiner zweiten Arbeitsstelle getestet und habe hier das gleiche Problem. Beides Dell-Rechner.
In der einen Arbeitsstelle ist es ein Optiplex 5040 und bei der anderen ein Optiplex 7050. Mittels Dell Command | Update (Sucht automatisch die aktuellen Treiber zum jeweiligen Dell-System) wurde sichergestellt, dass alles auf dem aktuellen Stand ist.
Die Ereignisanzeige sagt folgendes:

Name der fehlerhaften Anwendung: SysteminventoryV2.exe, Version: 1.0.0.0, Zeitstempel: 0x6377dc84
Name des fehlerhaften Moduls: ntdll.dll, Version: 10.0.19041.2130, Zeitstempel: 0xb5ced1c6
Ausnahmecode: 0xc0000374
Fehleroffset: 0x00000000000ff6a9
ID des fehlerhaften Prozesses: 0x3c48
Startzeit der fehlerhaften Anwendung: 0x01d9210924c48852
Pfad der fehlerhaften Anwendung: [..]\SysteminventoryV2\bin\Debug\net6.0-windows\SysteminventoryV2.exe
Pfad des fehlerhaften Moduls: C:\WINDOWS\SYSTEM32\ntdll.dll
Berichtskennung: [...]
Vollständiger Name des fehlerhaften Pakets: <Hier steht nichts>
Anwendungs-ID, die relativ zum fehlerhaften Paket ist:

Ich kann das bis Projekt das bislang gemacht wurde gerne hier reinstellen falls euch das helfen sollte mir zu helfen.

IDE: Visual Studio 2022
Sofern nicht anders genannt basieren meine Projekte auf C# und .net 6

4.931 Beiträge seit 2008
vor einem Jahr

Leider hilft hier die Ereignisanzeige nicht weiter, da hier nur die "ntdll.dll" steht und nicht die DLL der aufrufenden Funktion.

Gibt es denn nur bei PowerManager.PowerPersonality den Absturz oder auch bei anderen Eigenschaften?

Im Source-Code zu PowerPersonality sehe ich, daß der Rückgabewert nicht überprüft wird (s.a. Doku der nativen PowerGetActiveScheme-Funktion).
Vllt. führt dann bei einem Fehler der Aufruf von CoreNativeMethods.LocalFree(ref guid) zu dem Speicherfehler?

Du könntest also mal selber diese Eigenschaft bei dir selbst im Code unterbringen (also den Source-Code dazu kopieren) und den Rückgabewert (DWORD => uint) auf ERROR_SUCCESS (= 0) abfragen, und nur dann die Freigabe durchführen.

L
LittleTester Themenstarter:in
158 Beiträge seit 2019
vor einem Jahr

Ich habe das nun probiert, aber leider funktioniert das nicht. Ich habe den kompletten Code in eine eigene Klasse und am ende sogar in ein neues .net Framework 4.8 Projekt kopiert, weil "using Microsoft.WindowsAPICodePack.Resources;" in Version 7 des "Windows-API-CodePack-NET" nicht mehr unterstützt wird und ich dachte es liegt vielleicht daran. Habe deswegen Version 1.1.2 verwendet (das aber nicht .net Core 6 unterstützt) Daran lag es aber am ende nicht.

Fehler ist:

'Der Zugriff auf "PowerManagementNativeMethods" ist aufgrund des Schutzgrads nicht möglich.

Die dekompilierte Datei, bzw. Methode von MessageManager.cs beginnt dann auch mit


internal static class MessageManager
{
}

und logischerweise kann man das nicht mal eben testweise auf public ändern.
Jetzt bin ich überfordert.

Btw: Die Demo-App, basierend auf WPF funktioniert auch nicht. Die lässt sich zwar kompilieren, wirft beim Starten dann aber auch den Fehler im Ereignisprotokoll.

Ebenfalls interessant: Die Methode (GetSystemEnergyState()) aus meiner App die letztens auf meinem Rechner zu Hause noch funktionierte, funktioniert nun nicht mehr, hat dafür aber auf einem meiner Geschäftsrechner wo sie vorher nicht funktionierte plötzlich funktioniert. Muss man das verstehen?

IDE: Visual Studio 2022
Sofern nicht anders genannt basieren meine Projekte auf C# und .net 6

4.931 Beiträge seit 2008
vor einem Jahr

Die beiden Methoden PowerManagementNativeMethods.PowerGetActiveSchem und CoreNativeMethods.LocalFree sind einfach nur P/Invoke-Deklarationen, welche du einfach in deinen Code übernehmen kannst (und einen eigenen Klassennamen dafür nimmst).


internal static class MyNativeMethods
{
    [DllImport("powrprof.dll")]
    internal static extern int PowerGetActiveScheme( // <- hier schon den Rückgabetyp auf int (bzw. uint) geändert
            IntPtr rootPowerKey,
            [MarshalAs(UnmanagedType.LPStruct)]
            out Guid activePolicy);

    [DllImport("Kernel32.dll", EntryPoint = "LocalFree")]
    internal static extern IntPtr LocalFree(ref Guid guid);
}

(die Sichtbarkeit public oder internal kannst du selber festlegen)

Und dann nur die Eigenschaft in eine eigene Klasse übernehmen (und den möglichen Fehler abfangen):


public static PowerPersonality PowerPersonality
{
    get
    {
        Guid guid;
        var error = MyNativeMethods.PowerGetActiveScheme(IntPtr.Zero, out guid);

        try
        {
            return PowerPersonalityGuids.GuidToEnum(guid);
        }
        finally
        {
            if (error == 0)
                MyNativeMethods.LocalFree(ref guid);
        }
    }

Leider mußt du auch noch die (kleine) Klasse PowerPersonalityGuids in deinen Code übernehmen, da diese ebenfalls internal ist - auch hier dann, damit keine Konflikte entstehen, einen eigenen Klassennamen (bzw. Namespace) dafür benutzen.

Und dann kannst du ja testen, ob es keinen Speicherfehler mehr gibt und welchen Wert error hat.