• Hallo liebe Userinnen und User,

    nach bereits längeren Planungen und Vorbereitungen sind wir nun von vBulletin auf Xenforo umgestiegen. Die Umstellung musste leider aufgrund der Serverprobleme der letzten Tage notgedrungen vorverlegt werden. Das neue Forum ist soweit voll funktionsfähig, allerdings sind noch nicht alle der gewohnten Funktionen vorhanden. Nach Möglichkeit werden wir sie in den nächsten Wochen nachrüsten. Dafür sollte es nun einige der Probleme lösen, die wir in den letzten Tagen, Wochen und Monaten hatten. Auch der Server ist nun potenter als bei unserem alten Hoster, wodurch wir nun langfristig den Tank mit Bytes vollgetankt haben.

    Anfangs mag die neue Boardsoftware etwas ungewohnt sein, aber man findet sich recht schnell ein. Wir wissen, dass ihr alle Gewohnheitstiere seid, aber gebt dem neuen Board eine Chance.
    Sollte etwas der neuen oder auch gewohnten Funktionen unklar sein, könnt ihr den "Wo issn da der Button zu"-Thread im Feedback nutzen. Bugs meldet ihr bitte im Bugtracker, es wird sicher welche geben die uns noch nicht aufgefallen sind. Ich werde das dann versuchen, halbwegs im Startbeitrag übersichtlich zu halten, was an Arbeit noch aussteht.

    Neu ist, dass die Boardsoftware deutlich besser für Mobiltelefone und diverse Endgeräte geeignet ist und nun auch im mobilen Style alle Funktionen verfügbar sind. Am Desktop findet ihr oben rechts sowohl den Umschalter zwischen hellem und dunklem Style. Am Handy ist der Hell-/Dunkelschalter am Ende der Seite. Damit sollte zukünftig jeder sein Board so konfigurieren können, wie es ihm am liebsten ist.


    Die restlichen Funktionen sollten eigentlich soweit wie gewohnt funktionieren. Einfach mal ein wenig damit spielen oder bei Unklarheiten im Thread nachfragen. Viel Spaß im ngb 2.0.

[C#] System.NullReferenceException: "Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt."

Cyperfriend

Der ohne Avatar

Registriert
14 Juli 2013
Beiträge
1.123
Hallo,

ich hatte diesen Fehler bislang nur beim Debuggen einer Releaseversion und das wohl auch nur, weil ich da versuchshalber "Nur eigenen Code" ausgewählt habe. Blöderweise bekomme ich das auch nicht mehr weg. War mir bislang egal, habe ich halt immer im Debugmodus debugged.

Beim Debugen einer Debugversion hatte ich den Fehler bislang nicht, erst nachdem ich jetzt mal die ganzen Labels ordentlich benannt habe.

Der Fehler kommt in diesem Programmabschnitt. Der Programmteil hat bislang auch immer funktioniert. An Zugriffsrechten kann es nicht liegen. Das try/catch scheint den Fehler auch nicht abfangen zu können
[src=csharp] // Prüfen, ob Updates für andere Microsoft-Produkte aktiviert sind.
try
{
string omu = @"SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Services\7971F918-A847-4430-9279-4A52D1EFE18D";
RegistryKey omukey = Registry.LocalMachine;
RegistryKey oskkey = omukey.OpenSubKey(omu);

string rwau = oskkey.GetValue("RegisteredWithAU").ToString();
if (rwau == "1")
{
lblUpdateErweitert.Text = "Aktiviert";
}
else
{
lblUpdateErweitert.Text = "Deaktiviert";
}
}catch(Exception ex)
{
MessageBox.Show(ex.Message);
}[/src]

Anhang anzeigen 58482
 

drfuture

Zeitreisender
Teammitglied

Registriert
14 Juli 2013
Beiträge
8.728
Ort
in der Zukunft
Der Debugger möchte an der Stelle Informationen aus dem .NET Code abrufen den er nicht findet.

wenn du Einstellst das ausschließlich dein Code durchsucht werden darf und nicht der des Frameworks > Nicht gefunden > Fehler
wenn du eine Release-Version Debuggst > wird je nach Einstellung keine Datei mit Debug.Code Erstellt > Nicht gefunden > Fehler

Daher am besten die Einstellung mit dem eigenen Code wieder zurück stellen.
Das geht unter Extras > Optionen > Debugging > Allgemein

Hast du oben ein

Using System;

drin?
 

Cyperfriend

Der ohne Avatar

Registriert
14 Juli 2013
Beiträge
1.123
  • Thread Starter Thread Starter
  • #3
Also das ist jetzt wirklich nicht nach zu vollziehen.

Ich habe euch jetzt drei Projekte hochgeladen:
1) Das Backup, wo der Programmteil mit den Updates für andere Microsoft Produkte noch funktioniert
2) Der aktuelle Build wo das nicht mehr funktioniert
3) Ein komplett neues Projekt, dass nur den Registry-Key prüft und ebenfalls nicht funktioniert.

Der entsprechende Codeabschnitt ist immer gleich. Könnt ihr für Aufklärung sorgen, warum das in dem einen Projekt funktioniert und bei den anderen beiden plötzlich nicht mehr?
Das Verhalten ist auf meinem Privatrechner und dem Geschäftsrechner gleich.

Ich habe die Dateien auf MEGA hochgeladen, weil das hier nicht funktioniert (vermutlich zu groß, Fehlermeldung sagt aber, dass die Datei nicht vorhanden wäre)
https://mega.nz/file/gAxxiKBJ#TQZtvtGQqC1E8ZtB4RcqjffGZTbzc5pZAn8QCrQfWBs
 

KaPiTN

♪♪♫ wild at heart ♪♫♫♪

Registriert
14 Juli 2013
Beiträge
29.138
"Nur eigenen Code" ist aber der Standard und das ist auch vernünftig, will ich ja meinen Code durchgehen und nicht den des Frameworks durchlaufen, wenn ich eine dessen Funktionen aufrufe.
Und NullReferenceException bedeutet einen fehlenden Verweis, bzw. einen auf null. String ist ein Verweistyp.
Aber warum das bei der Erstellung per Zuweisung null sein sollte, kann ich so nicht nachvollziehen.

EDIT: Den letzten Post sehe ich jetzt erst. Ich schau mir das mal an.
 

KaPiTN

♪♪♫ wild at heart ♪♫♫♪

Registriert
14 Juli 2013
Beiträge
29.138
2) skey.GetValue("DisplayVersion") gibt null zurück. ->NullReferenceException. Die Abfrage ist in 1) nicht drin

3) oskkey.GetValue("RegisteredWithAU") ->NullReferenceException, weil oskkey null ist.
Bis Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ geht es, ab WindowsUpdate dann nicht mehr.
Fehlende Berechtigung?
 

Cyperfriend

Der ohne Avatar

Registriert
14 Juli 2013
Beiträge
1.123
  • Thread Starter Thread Starter
  • #6
Danke, dass du dich damit befasst hast.
Die Sache hat aber einige Haken:
1) Warum funktioniert der Code bei dem einen Projekt, bei den anderen beiden aber nicht, bzw. bei dem einen Projekt nicht mehr (hat da ja mal funktioniert. Mir ist nur nicht klar welche Änderung da plötzlich quer schießt und warum)
2) Auf meinem Privatrechner bin ich Admin und kann auch über regedit auf den Schlüssel zugreifen, sogar ändern
3) Ich habe die Programme auch bei meinem zweiten Arbeitgeber, wo ich definitiv nur Benutzerrechte habe, ausgeführt und das eine Programm funktioniert, die anderen beiden nicht. Auch bei meinem zweiten Arbeitgeber kann ich auf den Schlüssel zugreifen. (Ob ich ihn ändern kann habe ich nicht probiert, spielt zur Abfrage an sich aber eh keine Rolle)

[src=csharp] 2) skey.GetValue("DisplayVersion") gibt null zurück. ->NullReferenceException. Die Abfrage ist in 1) nicht drin[/src]
Das ist doch der Teil mit der Abfrage der OS-Version? Seltsam, der Teil hat bislang nirgendwo Probleme bereitet. Du hast Windows 10? (Das setze ich voraus, weil wir eh kein Windows 7 / 8 mehr haben)

Um die Sache dann aber endgültig verrückt zu machen:
Beim Projekt Systeminfo-Funktioniert_nicht knallt es hier:
[src=csharp]string omu = @"SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Services\7971F918-A847-4430-9279-4A52D1EFE18D";
[/src]

Beim Projekt OtherMicrosoftUpdates knallt es hier:
[src=csharp]string rwau = oskkey.GetValue("RegisteredWithAU").ToString();
[/src]

Der gleiche Code, Fehler an zwei unterschiedlichen Stellen und bei einem Projekt funktionierts wie es soll.
 
Zuletzt bearbeitet:

KaPiTN

♪♪♫ wild at heart ♪♫♫♪

Registriert
14 Juli 2013
Beiträge
29.138
1) Warum funktioniert der Code bei dem einen Projekt, bei den anderen beiden aber nicht, bzw. bei dem einen Projekt nicht mehr (hat da ja mal funktioniert. Mir ist nur nicht klar welche Änderung da plötzlich quer schießt und warum)

Es ist nicht der gleiche Code.Aber das ist in der Debugversion. Das merken wir uns für später.


skey.GetValue("DisplayVersion") gibt null zurück. ->NullReferenceException.

Systeminfo-Funktioniert
[src=csharp] // OS Abfragen über die Registrierung:
string subKey = @"SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion";
RegistryKey key = Microsoft.Win32.Registry.LocalMachine;
RegistryKey skey = key.OpenSubKey(subKey);
string ReleaseId = skey.GetValue("ReleaseId").ToString();[/src]

Systeminfo-Funktioniert_nicht
[src=csharp]// OS Abfragen über die Registrierung:
string subKey = @"SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion";
RegistryKey key = Microsoft.Win32.Registry.LocalMachine;
RegistryKey skey = key.OpenSubKey(subKey);
string ReleaseId = skey.GetValue("ReleaseId").ToString();
string DisplayVersion = skey.GetValue("DisplayVersion").ToString();[/src]

Zum eigentlichen Problem

Beim Projekt OtherMicrosoftUpdates knallt es hier:
[src=csharp]string rwau = oskkey.GetValue("RegisteredWithAU").ToString();
[/src]

.

Weil RegistryKey oskkey = omukey.OpenSubKey(omu); null zurück gibt.
Bis Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ kommt ein Wert zurück, aber schon Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ WindowsUpdate nicht mehr.
Fehlende Berechtigung?

Zur Eingangsfrage
: Die Fehlermeldung kommt an der falschen Stelle, wo gar kein Fehler vorliegt. Da kommt der Debugger irgendwie durcheinander, weil Du da im Release-Modus bist, wo Codeoptimierungen durchgeführt werden.
Bei OtherMicrosoftUpdates habe ich auch mal im Release getestet und auch da kam der Fehler an unerwarteter Stelle.

Nächster Schritt wäre dann wohl herauszufinden, warum der Zugriff auf den Subkey nicht funktioniert.
 

drfuture

Zeitreisender
Teammitglied

Registriert
14 Juli 2013
Beiträge
8.728
Ort
in der Zukunft
Thx KaPiTN - auf debug im Release und komischen Zeilen bin ich auch schon reingefallen... da sollte man vor warnen. Daran habe ich nun auch nicht gedacht.
Debug auf Debug-Einstellung :T. Und ja daran dürfte die Codeoptimierung schuld sein.

Auf die oben angegebene Reg-Keys haben Benutzer grundsätzlich Leserechte (Das kann man zwar in der Tat auch ändern - aber ich gehe nun mal nicht davon aus das bei euch jemand die Rechte der System-Hives verändert).

Ein Grund könnte aber ein laufender Virenscanner sein der die Handlungen deines Programms für suspekt hält. Wenn da eine Verhaltenskontrolle anschlägt könnte das auch ein "mal gehts und mal nicht" erklären - je nachdem wie sich die Anwendung zuvor verhalten hat kann sich die Schutzsoftware leider anders entscheiden.
 

Cyperfriend

Der ohne Avatar

Registriert
14 Juli 2013
Beiträge
1.123
  • Thread Starter Thread Starter
  • #9
Also den Release-Modus habe ich schon lange aufgegeben. Ich benutze immer den Debug-Modus

Auf meinem Privatrechner habe ich kein AV-Programm, nur den Defender. Auf dem Rechner meines zweiten Arbeitgebers ist McAfe drauf und wenn der anschlägt bekomme ich (und alle anderen IT Koordinatoren) eine E-Mail darüber. Nichts dergleichen ist passiert.

Wie verhalten sich die Programme den bei euch? Funktionieren alle drei Versionen nicht oder funktioniert den wenigstens auch die eine, die auch bei mir funktioniert?
 

drfuture

Zeitreisender
Teammitglied

Registriert
14 Juli 2013
Beiträge
8.728
Ort
in der Zukunft
Ich schau mal ob ich am Nachmittag dazu komme - dann teste ich sie mal....
Habe - um die Sache noch ein wenig Interessanter zu machen auf Visual Studio 2017 und 2019 ;p
 

KaPiTN

♪♪♫ wild at heart ♪♫♫♪

Registriert
14 Juli 2013
Beiträge
29.138
Also den Release-Modus habe ich schon lange aufgegeben. Ich benutze immer den Debug-Modus

Auch hier Vorsicht!

Wenn da oben in der Leiste "debug" steht, dann ist das die Projektmappenkonfiguration.
Ob Du auch für dein Projekt tatsächlich den Debugmodus aktiviert hast, siehst Du, wenn Du da den Konfigurationsmanager öffnest, wo für jedes Projekt der Mappe einzeln konfiguriert werden kann.

-
 
Zuletzt bearbeitet:

KaPiTN

♪♪♫ wild at heart ♪♫♫♪

Registriert
14 Juli 2013
Beiträge
29.138
So. Jetzt wollte ich es selber aber auch wissen.

Man muß schon angeben, wo gesucht werden soll.

Statt
[src=csharp]RegistryKey omukey = Registry.LocalMachine;[/src]


also
[src=csharp] var omukey = RegistryKey.OpenBaseKey
(RegistryHive.LocalMachine, RegistryView.Registry64);

[/src]
 

Cyperfriend

Der ohne Avatar

Registriert
14 Juli 2013
Beiträge
1.123
  • Thread Starter Thread Starter
  • #13
Das mit dem Debugmodus, der "intern" auf Release stand war aber echt fies. Habs umgestellt und nun läuft es. Komisch, dass das auch bei einem neu erstellten Projekt so war, aber beim Laden des Backup-Projekts nicht. Muss man drauf kommen. Danke.

Woher weis man eigentlich, ob man die "normale" Registry braucht oder die x64-Registry? Seit dem Einfügen deines überarbeiteten Code funktioniert der Codeabschnitt auch unter einem "Release"-Debug.
 
Zuletzt bearbeitet:

drfuture

Zeitreisender
Teammitglied

Registriert
14 Juli 2013
Beiträge
8.728
Ort
in der Zukunft
@x64-Registry Windows trennt strickt zwischen 32bit und 64bit "Umgebung".
Aus Sicht einer 32bit Anwendung erscheinen div. Pfade oder auch Regkeys im OS anders. z.B. hklm:\Software\WOW6432Node\ ist der Inhalt den eine 32bit Anwendung unter HKLM:\Software sieht.
Ähnlich sieht das mit c:\Programme / c:\Programme (x86) oder c:\windows\system und c:\windows\syswow64\ aus.

Wenn du nun deine Anwendung als 64bit Anwendung Kompilierst ist die Standard-Einstellung das er die 64bit Ansicht wählt. bei einer 32-Bit Anwendung eben die 32-Bit Ansicht. Über den Schalter kannst du das Verhalten dann aber noch extra beeinflussen.

https://docs.microsoft.com/de-de/dotnet/api/microsoft.win32.registryview?view=dotnet-plat-ext-5.0
 
Oben