[.NET]System.NullReferenceException event in eventviewer

[Damic]

Mijn vraag
Goed mijn zelf gemaakt programma heeft soms de neiging om ineens te stoppen zonder JIT error. Nu heb ik gezien in eventviewer dat er daar wel een mooie error staat maar daar ben ik op het eerste gezicht niet veel mee.

Er staan telkens 2 errors vlak onder elkaar:
1ste

code:

Application: Tray Streamer.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.NullReferenceException

2de

code:

Faulting application name: Tray Streamer.exe, version: 23.10.4.0, time stamp: 0x651dbb2d
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x00007ffae8c7158d
Faulting process id: 0x28ac
Faulting application start time: 0x01da2ebe83e6e9a7
Faulting application path: C:\CD-PC\Tray Streamer\Tray Streamer.exe
Faulting module path: unknown
Report Id: 1c304109-7ffb-4049-9755-57cce3b6035c
Faulting package full name: 
Faulting package-relative application ID:

Hoe kan ik uit deze 2 errors halen waar ongeveer de fout zit?

Relevante software en hardware die ik gebruik
VS 2022 + W10

Wat ik al gevonden of geprobeerd heb
Als ik in debugger laat draaien dan is er niets mis

Nog niets anders geprobeerd want weet niet waar ik moet zoeken, de fout kan voorkomen in seconden tot dagen.

[Cyphax]

Ik denk dat je eerst zinvolle logging moet toevoegen aan je applicatie op plekken waar het risico op nullreferenceexceptions het grootst is en dan daar kijken op de momenten dat het mis gaat. Ik weet niet hoe groot je applicatie is, maar .net waarschuwt je tegenwoordig redelijk uitvoerig voor potentiele nulls. Ik zou met deze informatie verder niet zo heel veel kunnen.

[Damic]

Welke logging kun je me eventueel aanraden? Ik had zelf iets geschreven maar vermits het onmiddellijk een NullRef is word er niets weggeschreven.

Edit: dit (https://stackoverflow.com...xecutable-into-a-debugger) eens geprobeerd en BINGO

Managed Debugging Assistant 'CallbackOnCollectedDelegate' : 'A callback was made on a garbage collected delegate of type 'Bass.Net!Un4seen.Bass.SYNCPROC::Invoke'. This may cause application crashes, corruption and data loss. When passing delegates to unmanaged code, they must be kept alive by the managed application until it is guaranteed that they will never be called.'

Damn hoe moet ik dat oplossen, dat is een extern dll die word onderhouden door 3de partij

[ Voor 72% gewijzigd door Damic op 14-12-2023 20:30 ]

[dfijma]

Nu heb ik sinds een jaar of 20 niet meer zoveel verstand van Windows- en/of .NET-ontwikkeling, maar het moet toch mogelijk zijn om ergens te loggen op welke regel die NullReferenceException optreedt? Zoals in Java, waar je op een of andere plek op een "hoog" niveau van je applicatie (in de main-loop ofzo) een "catch (Exception e)" plaatst en dan een stacktrace logt.

Als je de regel weet, weet je ook welke variabele (waarschijnlijk) "null" is. En dan maar nadenken WAAROM die null kan worden terwijl jouw programma dat niet verwacht.

Educated guess: het treedt niet op de debugger en als het WEL optreedt is het soms na enkele secoden en soms na enkele uren. Dat doet denken aan een race-conditie in een multithreaded applicatie. Die variabele wordt door de ene thread onder specifieke condities op null gezet terwijl de andere thread 'm net wil dereferencen => BOEM. Mind you, zelfs met een check als:

code:

if (reference != null) {
    this.doeIetsMet(reference.haalIetsOp()) 
}

kan je programma crashen met een NRE als SOMS, net tussen de check en feitelijke dereference 'reference.haalIetsOp()', een andere thread die reference op null zet.

[Damic]

@dfijma dank je voor je bijdrage maar het gebeurd dus niet direct in mijn programma maar in de bass.net module(s) (zie mijn edit in vorige post).

Nu moet ik dus eens kijken of ik daar direct iets van kan vinden en wat de eventuele oplossing is.

[dfijma]

[b]Damic in "[.NET]System.NullReferenceException event in eventviewer" het gebeurd dus niet direct in mijn programma maar in de bass.net module(s) (zie mijn edit in vorige post).

OMG. Unmanaged code. Ja, dat hebben wij in Java ook

Geen idee wat bass.net doet of is, maar dit is wel een hint ja. Je hebt in jouw code een of ander object (in "managed code", doe je C# ofzo?). Een referentie naar dat object geef je mee in een call naar bass.net. Direct daarna verdwijnt "jouw" object (bijvoorbeeld, omdat de enige "managed" verwijzing een lokale variabele is en de functie waarin die variabele van een waarde is voorzien een return doet). De garbage-collector weet niet beter dan dat jouw object garbage is en ruimt het op (op een onvoorspelbaar moment). De unmanaged code heeft een referentie naar het inmiddels ongeldige object => BOEM

[Damic]

Bass.net is een audio module http://bass.radio42.com/ mijn programma is in VB.net, maar nu ik SYNCPROC zien staan denk ik dat ik al weet waar ik moet zoeken

Komt goed komt goed

[Haan]

Twee dingen:
1. logging schrijf je niet zelf, dat hebben anderen al lang voor jou gedaan Meest eenvoudige optie is om gewoon de Microsoft logging libraries te gebruiken https://learn.microsoft.c...t/core/extensions/logging
2. Om je probleem op te lossen, moet je volgens mij gewoon even goed de help van die library lezen, met name het kopje Garbage Collection, wat precies lijkt te zijn waar jij tegenaan loopt nu

[Damic]

1. tja, zo uitgebreid moet het ook weer niet
2. ik vind het niet grappig dat ie in de Project release map al +8h40 aan't spelen is zonder te crashen, maar zodra ie in de andere map staat dan crasht ie

[RobIII]

Heb je al een unhandled exception handler geprobeerd? Daar kun je dan alsnog je exception loggen.
En anders een catch zonder (Exception ex), maar je hebt gewoon een CLS compliant exception dus dat zou niet nodig moeten zijn.

Damic schreef op vrijdag 15 december 2023 @ 09:00:
1. tja, zo uitgebreid moet het ook weer niet

Zo'n tried & tested oplossing werkt geheid véle malen beter dan je eigen Logfile.Writeline(ex.Message)...

Cyphax schreef op donderdag 14 december 2023 @ 20:16:
Ik weet niet hoe groot je applicatie is, maar .net waarschuwt je tegenwoordig redelijk uitvoerig voor potentiele nulls.

Voor C# krijg je idd waarschuwingen van je compiler in je IDE (mits de 'nullable feature' aan staat), maar VB.Net is (ook) op dat vlak blijven steken

[ Voor 95% gewijzigd door RobIII op 15-12-2023 10:00 ]

[Damic]

Ow ik had nog een sub zonder try catch in en die word af en toe aangeroepen door de SYNCPROC, maar vind het nog altijd raar dat ie zegt dat de delagate weg is terwijl ik dat niet initieer.

Die unhandled exception handler is wel een handige.

En "juist" een build gemaakt en de exe verplaatst van map en speelt al +12 minuten, geen extra fout meldingen of crashes. Ik verdenk nog altijd .net van het probleem

Edit:

Zo'n tried & tested oplossing werkt geheid véle malen beter dan je eigen Logfile.Writeline(ex.Message)...

ssssht
voor nulls krijg je meestal een JIT error (als ik me niet vergis, wat wel eens goed voorkomt ) als je geen catch gebruikt.

[ Voor 24% gewijzigd door Damic op 15-12-2023 10:15 ]

[RobIII]

Damic schreef op vrijdag 15 december 2023 @ 10:11:
voor nulls krijg je meestal een JIT error (als ik me niet vergis, wat wel eens goed voorkomt ) als je geen catch gebruikt.

Er is niet zoiets als een "JIT error", geen idee waar je 't over hebt
Even de edge-case daargelaten waar "de JITter" zélf misschien op z'n nek gaat ofzo, maar dat is totaaaaal andere koek en staat hier compleet los van. "De JITter" genereert code, hij voert 't niet uit, dat doet de runtime (je processor ultimately natuurlijk).

Damic schreef op vrijdag 15 december 2023 @ 10:11:
Ik verdenk nog altijd .net van het probleem

Ik verdenk onjuist gebruik van .Net

[ Voor 50% gewijzigd door RobIII op 15-12-2023 10:48 ]

[Damic]

Goed gisteren een nieuwe build gemaakt en de installer een rebuild laten doen en na het installeren kwam ik op hetzelfde probleem en in event viewer word je er soms ook niet veel wijzer uit.
Eerste fout: Faulting module name: System.Windows.Forms.ni.dll, version: 4.8.9181.0, time stamp: 0x64b87db6
2de keer geïnstalleerd: Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000 zelfs geen module niet meer
nog maar eens proberen: Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000 zelfde fout.

Heb dan de installer nog eens rebuild laten doen en nu werkt het terug.

Juist een sfc /scannow laten doen en er waren fouten gevonden en gecorrigeerd. Ben eens benieuwd of het dat was of het toch dieper zit in de hardware.

[farlane]

Nou, als die exception in unmanged stuff wordt getriggered kan er best wel een heleboel kapot zijn, inclusief de mogelijkheid van je systeem om te loggen wat er kapot is.

Aan je omschrijving te zien lijkt het er op dat je een resource (buffer voor Audio samples?) moet blijven vasthouden omdat anders de GC langskomt en het ding collect terwijl de library er nog mee bezig is.

[Damic]

Ik vermoed dat er iets mis is met de samsung 970 alles wat ik copier naar daar of vanaf daar gaat iets mis mee. Juist ook weer een update voor android (van foon naar pc > uitgepakt > boot.img terug naar foon > magisk erop los gelaten > terug naar pc > in de zip gezet > zip terug naar foon en na het flashen een boot error). Terug al die handelingen gedaan en nu geen problemen meer.

Edit: juist misschien heeft die ssd een update nodig edit2 geen update nodig

[ Voor 8% gewijzigd door Damic op 04-02-2024 17:23 ]

[RobIII]

Doe eens gek en trek een hash van voor en na van je files en kijk of de files nog in tact zijn?

[farlane]

Damic schreef op zondag 4 februari 2024 @ 15:16:
Ik vermoed dat er iets mis is met de samsung 970 alles wat ik copier naar daar of vanaf daar gaat iets mis mee. Juist ook weer een update voor android (van foon naar pc > uitgepakt > boot.img terug naar foon > magisk erop los gelaten > terug naar pc > in de zip gezet > zip terug naar foon en na het flashen een boot error). Terug al die handelingen gedaan en nu geen problemen meer.

Edit: juist misschien heeft die ssd een update nodig edit2 geen update nodig

Dat klinkt vrij onwerkelijk, ik zie niet in waarom je disk dit zou veroorzaken.Wishful thinking wellicht....

[Damic]

Ik zou het ook niet weten maar gebeurd alleen op die schijf. Het moet van ergens komen he en is niet continu.

@RobIII juist gedaan en de hashes kloppen van na een nieuwe kopie beurt

[farlane]

Timing issue wellicht, de bug zit in je code (of in die van de library)

[Damic]

Hoe komt het dan als ik het zelfde programma op een andere schijf start dat ie dat dan niet heeft, hell zelfs andere pc's.

[CodeCaster]

Damic schreef op zondag 4 februari 2024 @ 20:05:
Hoe komt het dan als ik het zelfde programma op een andere schijf start dat ie dat dan niet heeft, hell zelfs andere pc's.

Dat kan om oneindig veel redenen, hardcoded paden om te beginnen. Zonder code is er niks zinnigs te zeggen. Als je regelnummers wil, zul je de PDB's moeten deployen naast de executable, en de stack trace moeten loggen. Dan weet je in ieder geval waar in de code de exception wordt gegooid.

[Damic]

Ik denk dat ik het gevonden heb want had weer een rariteit.

Nu zat het in het updater gedeelte en melde Eventviewer een probleem met flurl dat er iets niet goed werd afgehandeld, wat ik al raar vind want het staat in een try catch statement.

Application: Tray Streamer.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.IO.FileLoadException

Exception Info: System.IO.FileLoadException
at System.Signature.GetSignature(Void*, Int32, System.RuntimeFieldHandleInternal, System.IRuntimeMethodInfo, System.RuntimeType)
at System.Reflection.RuntimeConstructorInfo.GetParametersNoCopy()
at System.Reflection.RuntimeConstructorInfo.GetParameters()
at System.Diagnostics.StackTrace.ToString(TraceFormat)
at System.Exception.GetStackTrace(Boolean)
at System.Exception.ToString(Boolean, Boolean)
at System.Exception.ToString(Boolean, Boolean)
at System.Exception.ToString(Boolean, Boolean)
at System.AggregateException.ToString()
at Tray_Streamer.modUpdate.Http_Request(System.String, System.String, Boolean, System.String)
at Tray_Streamer.modUpdate.ThreadUpdate()
at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
at System.Threading.ThreadHelper.ThreadStart()

Maar wat ik gedaan had was de exe die uit de debug komt, de exe die uit de release kwam overschreven. Als ik de exe van de release nam dan was alles terug goed.

Er zit dan toch een rariteit ergens in exe/dll's die in de mappen van release en de debug staan.

[MatHack]

Deze error wijst op een assembly (lees: DLL) die niet gevonden kan worden voor de Reflection die gebruikt wordt om de stacktrace te bepalen. Ik vermoed dat er een andere versie van de assembly verwacht wordt dan in de map staat.

[Onbekend]

Die 0xC0000005-error heeft te maken met bestandstoegang.
Vaak ontstaat deze fout vanwege problemen met leesrechten, het bestand bestaat niet meer, of via het netwerk wordt het bestand geladen en het is een netwerkprobleem.

Als jouw applicatie zelf een bestand heeft gedownload of heeft gekopieerd, zit het wel goed met de leesrechten.
Staat het bestand op een lokale schijf, kijk dan eens of een antivirusprogramma roet in het eten gooit. Mogelijk dat deze tijdelijk de toegang tot het bestand beperkt totdat deze is gescand of malware en virussen.
Als een deel op een netwerklocatie staat, probeer dan eens eerst om alles op lokale schijven te zetten.

[RobIII]

...of er een een Debug build gedaan voor de PDB's en daarna een Release build voor een "release .exe" en zijn die met elkaar gemixed in de program files map. Quite honestly verwacht ik dat dat stiekem het probleem is.

[ Voor 33% gewijzigd door RobIII op 04-03-2024 23:13 ]