vb@rchiv
VB Classic
VB.NET
ADO.NET
VBA
C#
Erstellen von dynamischen Kontextmen?s - wann immer Sie sie brauchen!  
 vb@rchiv Quick-Search: Suche startenErweiterte Suche starten   Impressum  | Datenschutz  | vb@rchiv CD Vol.6  | Shop Copyright ©2000-2024
 
zurück

 Sie sind aktuell nicht angemeldet.Funktionen: Einloggen  |  Neu registrieren  |  Suchen

VB.NET - Fortgeschrittene
Fehler zur Lauzeit und zur Entwicklungszeit, aber nicht beim Debuggen 
Autor: Wasi_LE
Datum: 28.02.21 14:15

Guten Tag,
folgende Situation:
ich habe in einer Prozedur ein Try / Catch. Im Try-Abschnitt wird aus der Registry der Wert eines Schlüssels gelesen. Zur Laufzeit und zur Entwicklungszeit wird leider ein leerer Wert zurück gegeben, auch wenn dort im Schlüssel definitiv ein Wert enthalten ist. Wenn ich im Debug-Modus Zeile für Zeile durchgehe, wird der richtige Wert aus der Registry zurückgegeben.
Hat jemand eine Idee, wo der Hund begraben liegt?

Try
  Dim RegistryKnoten As String = "Software\MeineFirma\MeineSoftware 1.0"
  Dim RK As RegistryKey = Registry.LocalMachine.OpenSubKey(RegistryKnoten)
  Dim RKKey As String = RK.GetValue("RegKey").ToString
  RK.Close()
 
  If RKKey = "abc" Then
    MsgBox("erfolgreich")
  End If
 
Catch ex As Exception
  MsgBox("Fehler")
End Try
Vielen Dank.
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Fehler zur Lauzeit und zur Entwicklungszeit, aber nicht beim Debuggen 
Autor: effeff
Datum: 01.03.21 18:40

Vielleicht an den Rechten? Starte Deine Exe mal als Administrator...

EALA FREYA FRESENA

Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Fehler zur Lauzeit und zur Entwicklungszeit, aber nicht beim Debuggen 
Autor: Wasi_LE
Datum: 01.03.21 18:58

vielen Dank - das hatte ich schob probiert. Es ist ja auch nur ein Lesezugriff.

Was mich wundert ist, dass es völlig ausreicht, wenn ich beim Debuggen auf der Codezeile, in der das "Try" steht, einfach nur einen Stoppunkt setzen brauch. An der Stelle kurz angehalten und dann mit F5 weiter ausführen lassen, alles ist gut. Nehme ich den Stoppunkt wieder raus, geht´s nicht.

vG
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Fehler zur Lauzeit und zur Entwicklungszeit, aber nicht beim Debuggen 
Autor: effeff
Datum: 01.03.21 19:50

Dann nimm doch mal den Stoppunkt raus und füge bei "Catch" ein:

Messagebox.Show(ex.Tostring)
Dann sollte Dir angezeigt werden, wob ein Fehler kommt und wie der lautet.

EALA FREYA FRESENA

Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Fehler zur Lauzeit und zur Entwicklungszeit, aber nicht beim Debuggen 
Autor: Wasi_LE
Datum: 01.03.21 20:43

Catch wird nicht getriggert.
Es wird einfach der Schlüssel aus der
Registry nicht gelesen und statt dessen ein leerer String zurückgegeben ...
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Fehler zur Lauzeit und zur Entwicklungszeit, aber nicht beim Debuggen 
Autor: Kuno60
Datum: 01.03.21 22:42

Vielleicht ist dein Rechner zu schnell
Datei- und Registryzugriffe werden von Windows verwaltet. Dashalb kann es manchmal zu so einem Verhalten kommen.
Probiere mal den Code an einer anderen Stelle auszuführen, zum Beispiel beim Klick auf einen Button.
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Fehler zur Lauzeit und zur Entwicklungszeit, aber nicht beim Debuggen 
Autor: Wasi_LE
Datum: 02.03.21 06:18

Das ging mir auch schonmal durch den Kopf.
Hab ich aber kopfschüttelnd sofort wieder verwoverworfen, obwohl es sich bauchmäßig genau so anfühlt.
Dem entgegen spricht, dass ein Stopp in der Codezeile beim Try noch vor dem registryzugriff passiert.
Aber ich probiere es nachher aus und berichte dann ...
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Fehler zur Lauzeit und zur Entwicklungszeit, aber nicht beim Debuggen 
Autor: Wasi_LE
Datum: 02.03.21 08:33

Ich habe mal innerhalb des Try-Abschnitts als erstes vor dem lesen des Schlüssels eine MsgBox platziert. Dann funktioniert es. Irgendwie klingt es damit nach deiner Theorie, aber irgendwie will ich das nicht glauben. Soll ich da jetzt eine künstliche Bremse einbauen, damit das Programm funktioniert ? Und was ist, wenn der Kunde einen noch schnelleren Rechner hat ??? Oder in 5 Jahren die Rechner alle schneller sind ???
Irgendwie kann das nicht der richtige Weg sein...

Ich versuche mal, die Wert des Schlüssel in ein eigenes ReadOnly Property zu packen.

Hat jemand noch eine andere Idee ?

vG
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Fehler zur Lauzeit und zur Entwicklungszeit, aber nicht beim Debuggen 
Autor: Wasi_LE
Datum: 02.03.21 11:58

Irgendwie glaube ich es nicht, aber nachdem ich das nun in ein extra Property gelegt habe funktioniert alles.
Was bleibt, ist ein komisches Gefühl....

Dank für eure Hilfe...
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Fehler zur Lauzeit und zur Entwicklungszeit, aber nicht beim Debuggen 
Autor: Wasi_LE
Datum: 02.03.21 12:12

Entschuldigung, alles nochmal zurück.
Hatte vergessen eine MsgBox zu löschen.

Eine nichts sagende MsgBox an allererster Stelle im Get-Abschnitt des Property und alles ist gut. Lösche ich die, das alte Problem. Der Schlüssel wird leer zurück gegeben...

Was tun ?
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Fehler zur Lauzeit und zur Entwicklungszeit, aber nicht beim Debuggen 
Autor: effeff
Datum: 02.03.21 18:48

OK, hat ein bisschen gedauert...

Es gibt zwei Registrys; eine für 32-bit und eine für 64-bit. Du liest die falsche aus!

EALA FREYA FRESENA

Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Fehler zur Lauzeit und zur Entwicklungszeit, aber nicht beim Debuggen 
Autor: Wasi_LE
Datum: 03.03.21 08:31

Guten Morgen,
naja, ich hab da so meine Zweifel ... vielleicht kannst du das nochmal erklären, wie du das meinst.

für x86 CPU landen die Registryeinträge automatisch unter Software im WOW6432node. Wo die dann gelesen werden liegt doch dann daran für welche CPU du compilierst. Meine App wird 64bit, also liest er nicht im WOW6432Node.

Da VS2019 bei mir eine 32bit-Anwendung ist, habe ich es aber mal ausprobiert und die Anwendung für x86 CPU kompiliert -> gleiches Verhalten. Was noch dagegen spricht, ist, dass an anderer Stelle im Programm der Schlüssel geschrieben wird. Dies erfolgt ohne Probleme und der Schlüssel wird bei x86 CPU erwartungsgemäß im WOW6432Node/Software-Abschnitt geschrieben und bei x64 erwartungsgemäß im Software-Abschnitt nicht im WOW6432.

Welchen Einfluss sollte außerdem die MsgBox auf den Ort haben, aus dem der Schlüssel gelesen wird, die ich vor dem Lesen eingefügt habe und mit der es dann funktioniert.

Vielleicht hast du dazu eine Idee ?

Vielen Dank.
AW
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Fehler zur Lauzeit und zur Entwicklungszeit, aber nicht beim Debuggen 
Autor: Dilbert
Datum: 06.04.22 18:42

Hi,

ich würde davor statt 'ner msgbox mal ein "threading.thread.sleep(xxx)" bauen und austesten ob es wirklich am Timing liegt, und falls ja, wie viel "bremse" er braucht.

Bye,

Dilbert

--
while (!asleep()) sheep++;

Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Sie sind nicht angemeldet!
Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden.

Einloggen  |  Neu registrieren

Funktionen:  Zum Thema  |  GesamtübersichtSuchen 

nach obenzurück
 
   

Copyright ©2000-2024 vb@rchiv Dieter Otter
Alle Rechte vorbehalten.
Microsoft, Windows und Visual Basic sind entweder eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern. Weitere auf dieser Homepage aufgeführten Produkt- und Firmennamen können geschützte Marken ihrer jeweiligen Inhaber sein.

Diese Seiten wurden optimiert für eine Bildschirmauflösung von mind. 1280x1024 Pixel