[vstudio .net 2003] debuggen van applicatie

[JamesTiberius]

ik heb het probleem dat mijn vb.net win32 applicatie (voert om de zoveel tijd enkele taken uit) 'ergens' op blijft hangen. Met nadruk op 'ergens' ik kan de code natuurlijk enigzins volgen met breakpoints, het probleem is, mijn programma start en werkt goed, tot hij dus op een bepaald moment gewoon niet verder gaat met uitvoeren.

mijn probleem is nu dat ik, door mijn beperkte kennis van visual studio .net niet kan zien _waar_ het ergens fout gaat, het liefst heb ik gewoon een dikke vette foutmelding. Maar helaas, ...

Ik zou toch denken dat je op zo een moment in de code kunt springen en op kunt vragen wat de laatst uitgevoerde instructie is??

Mijn vraag is nu -> waar is deze optie te vinden?? Het jump-into icoontje is grijs terwijl de applicatie nog loopt, ...

aanvullend:
een hier mee betrekking hebbende vraag, mocht iemand mij hier een richting uit kunnen sturen: is het mogelijk om om op het uitvoeren van een functie een maximale tijdsduur te zetten?

[ Voor 14% gewijzigd door JamesTiberius op 21-04-2004 16:55 . Reden: aanvullend: ]

[Crysania]

zodra je op een breakpoint staat doe je step over of step into, zodat je verder gaat. zo verder steppen tot hij er in eens uitvliegt.

hierna ga je met watches kijken waarom hij er uit vliegt

[ Voor 4% gewijzigd door Crysania op 21-04-2004 17:28 ]

[Infinitive]

Ik zou toch denken dat je op zo een moment in de code kunt springen en op kunt vragen wat de laatst uitgevoerde instructie is??

Dat is toch gewoon de "break" (pauze knop)...? Dan kan je in het threadmenu de thread selecteren waarna je wilt kijken, en verder via het callstack menu kijken wat die thread vervolgens aan het doen is. In je code zet de debugger een pijltje met waar 'ie gebleven is.

[EfBe]

In de debugger de applicatie runnen. Op een gegeven moment gaat hij dus in de 'hang' mode, dus hij hangt zoals je zelf zegt, en dan klik je op de pause button in de debug toolbar (of cntrl-break). De code stopt dan in de routine waar het programma hangt. Dan naar de callstack kijken en je kunt zien hoe het programma daar komt en dus ook via de locals waar hij op hangt.

[JamesTiberius]

EfBe schreef op 21 april 2004 @ 17:33:
In de debugger de applicatie runnen. Op een gegeven moment gaat hij dus in de 'hang' mode, dus hij hangt zoals je zelf zegt, en dan klik je op de pause button in de debug toolbar (of cntrl-break). De code stopt dan in de routine waar het programma hangt. Dan naar de callstack kijken en je kunt zien hoe het programma daar komt en dus ook via de locals waar hij op hangt.

Ik krijg dan een (mooie) groene pijl op 'public class frmMain' (form van mijn app) in de call stack staat op
regel1: [<non user code>]
regel2: mijnApp.exe!mijnApp.frmMain.Main() line 10 + 0x1d bytes

eigenlijk staat hij op een stuk code wat mij absoluut niets zegt, ...

edit: als ik vervolgens op 'step into' klik krijgt mijn applicatie weer de focus en gaat vb wer op run mode ... en mijn applicatie blijft maar wachten op iets

[ Voor 12% gewijzigd door JamesTiberius op 21-04-2004 18:57 ]

[EfBe]

Kies eens in de build configuration 'debug' ipv 'release' Zo te zien build je een release build

[JamesTiberius]

EfBe schreef op 21 april 2004 @ 20:44:
Kies eens in de build configuration 'debug' ipv 'release' Zo te zien build je een release build

Helaas, is toch echt een debug build

Is overigens wel opgelost, niet door de debugfunctonaliteit, maar door per-ongeluk een declaratie aan te passen ...

wat ik doe: onformload maak ik een timer aan die om de paar seconden een thread aanmaakt en daarin een functie aanroept. Op de een of andere manier stopte die timer met werken (terwijl andere timers wel doorliepen zonder problemen).

nu bleek de oplossing te zijn de timer te declaren als public variabele binnen mijn class frmMain. dit ipv 'gewoon' declareren binnen frmMain.

wat hierin de logica in is kan ik niet echt begrijpen.

het verklaard wel waarom de debugger niets liet zien -> er valt niets te debuggen. zover visual studio weet doet mijn programma gewoon zijn werk.

Case closed dus.

in ieder geval bedankt voor de moeite.

[whoami]

JamesTiberius schreef op 21 april 2004 @ 21:53:
[...]

wat ik doe: onformload maak ik een timer aan die om de paar seconden een thread aanmaakt en daarin een functie aanroept. Op de een of andere manier stopte die timer met werken (terwijl andere timers wel doorliepen zonder problemen).

Dat klinkt niet als een ideale situatie.
Waarom lanceer je niet 1 thread, die zelf altijd een tijdje slaapt vooraleer ie verder doet , of die functie nog eens uitvoert?

[JamesTiberius]

whoami schreef op 21 april 2004 @ 21:59:
[...]

Dat klinkt niet als een ideale situatie.
Waarom lanceer je niet 1 thread, die zelf altijd een tijdje slaapt vooraleer ie verder doet , of die functie nog eens uitvoert?

de gedachte erachter is alles zo eenvoudig mogelijk te houden, ik start een functie in een thread, is de functie klaar dan is de thread afgelopen en met de timer controleer of ik hem opnieuw moet starten.

ik kan dan 'zien' of een functie goed uitvoert of blijft hangen en eventueel de beheerder een alert geven. het programma voert ook meerdere functies tegelijk uit op een verschillende interval. Loopt een functie 'vast' dan mag de rest daar geen last van hebben.

tot nu toe werkt dat prima. zolang ik mijn timer maar globaal declareer zo te merken

kan me overigens heel goed voorstellen dat er een betere manier is, maar ik kan me er zo geen verzinnen, moet er ook bij zeggen, ben 'van huis uit' een asp programmeur, zoals je ziet probeer ik, nu ik scripts moet uitvoeren in vb.net dezelfde situatie van 'batch verwerking' na te bootsen. ik weet nog lang niet alles mbt threading, vrijgeven van resources, hoe alles elkaar kan beinvloeden etc. maar dit lijkt gewoon goed te werken.

heb overigens stiekem de hoop dat variabelen en objecten die ikzelf niet opruime vanzelf opgeruimd worden als de thread afgelopen is (is toch wel zo?)

[ Voor 15% gewijzigd door JamesTiberius op 21-04-2004 23:01 ]