[VB6] dr. Watson NtWaitForSingleObject - Softwareontwikkeling

dinsdag 2 juli 2002 11:01

Acties:

Verwijderd

Topicstarter

Ik krijg de bovenstaande dr. Watson foutmelding als ik mijn programma sluit ... Het programma doet niets anders dan een object aanmaken en vrijgeven ... Dit aanmaken en vrijgeven kan ik runtime zo vaak doen als ik wil, geeft geen fout ... Pas op het moment dat ik het programma stop begint VB met deze dr. Watson error te gooien ... Het ergste is dat hij me VB ook maar meteen afsluit ... Niet leuk dus ...

Hier volgt de noodzakelijke code:

code:

   'declaratie variabele
   Dim myOLE As Object

   'object aanmaken
   Set myOLE = CreateObject("TDSAPI.FileServer")

   'object vrijgeven
   Set myOLE = Nothing

dinsdag 2 juli 2002 12:31

Acties:

Verwijderd

Zou je niet de typelib eens als reference opgeven in je VB project, zodat je niet 'As Object' hoeft te definieren maar meteen met het gewenste type. Je kunt dan ook gewoon 'New' gebruiken. Werkt dat wel?

dinsdag 2 juli 2002 13:16

Acties:

Verwijderd

Topicstarter

Dat typelib zou niet te hoeven ... Hij vindt dat ding toch ... Het is trouwens een geregistreerde ActiveX lib dus wat zou ik voor type op moeten geven ??? In Delphi zou het een OleVariant zijn, maar VB schijnt dit type niet te bezitten ... Dus ga ik dat 'new' maar eens uitproberen ...

dinsdag 2 juli 2002 13:33

Acties:

Crazy D

I think we should take a look.

Op dinsdag 02 juli 2002 13:16 schreef Norrit het volgende:
Dat typelib zou niet te hoeven ... Hij vindt dat ding toch ... Het is trouwens een geregistreerde ActiveX lib dus wat zou ik voor type op moeten geven ??? In Delphi zou het een OleVariant zijn, maar VB schijnt dit type niet te bezitten ... Dus ga ik dat 'new' maar eens uitproberen ...

Toevoegen aan je references en dimmen als
Dim blah As TDSAPI.FileServer
Set blah = New TDSAPI.FileServer

Exact expert nodig?

dinsdag 2 juli 2002 16:16

Acties:

Verwijderd

Topicstarter

Geprobeerd ... Fout blijft hetzelfde ... Toch bedankt ...

dinsdag 2 juli 2002 16:42

Acties:

Verwijderd

Fout ligt zeer waarschijnlijk in het component die niet een reference/resource vrijgeeft bij het 0 worden van zn refcount.

dinsdag 2 juli 2002 18:09

Acties:

Crazy D

I think we should take a look.

Op dinsdag 02 juli 2002 16:42 schreef Otis het volgende:
Fout ligt zeer waarschijnlijk in het component die niet een reference/resource vrijgeeft bij het 0 worden van zn refcount.

Dat zou ook nog kunnen ja, misschien is er een cleanup functie die je moet aanroepen?

Exact expert nodig?

woensdag 3 juli 2002 10:04

Acties:

Verwijderd

Topicstarter

Nee, die dll heeft geen cleanup-functie ... Dr. Watson geeft trouwens weer dat het mis gaat in de functie 'NtWaitForSingleObject' ... Misschien dat iemand hier meer aan heeft ... mijn MSDN werkt niet meer goed en ik kan dus ook niet opzoeken wat hier nu echt fout gaat, maar ik vermoed dat een geheugenplekje niet goed vrijgegeven wordt ... Oplossing = ???

donderdag 4 juli 2002 00:28

Acties:

Verwijderd

Nee, die dll heeft geen cleanup-functie ... Dr. Watson geeft trouwens weer dat het mis gaat in de functie 'NtWaitForSingleObject' ... Misschien dat iemand hier meer aan heeft

NtWaitForSingleObject is een NT Native API. Je moet wel heel erg foute dingen doen wil het hier fout gaan.
In eerdere versies van Win NT schijnen wel wat bugs gezeten te hebben in de Native NT API's die in een van de SP's zijn gefixed. Garbage in -> Garbage out.

Zet Dr. Watson eens uit. Wat voor fout krijg je dan?

donderdag 4 juli 2002 08:49

Acties:

Verwijderd

Topicstarter

dr. Watson uit ... Geen fout ... Het hele vreemde is dat als ik een Delphi-dll als wrapper gebruik en die dll daar dynamisch inlaad en vrijgeef, alles goed lijkt te gaan ...

Dit vind ik persoonlijk geen oplossing, maar totdat er geen beter alternatief zich voordoet, moet het maar zo ... Liever had ik de oplossing binnen VB gehouden ... Moet ik soms extra UpdatePacks over VB heengooien die het probleem van vrijgeven verhelpen ???

donderdag 4 juli 2002 08:53

Acties:

Verwijderd

dat object is 'verrot' (slechte coders). . .ander object zoeken

donderdag 4 juli 2002 09:15

Acties:

farlane

Bekijk de call stack eens in je DrWatson log. Vanuit waar wordt die NtWaitForSingleObject aangeroepen.
Meestal is een crash waarbij je processen (bijna) allemaal in die functie blijven hangen, een deadlock probleem.

Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.

donderdag 4 juli 2002 09:41

Acties:

Verwijderd

ntwaitforsingleobject is een OS functie uit de onderste regionen, dus de undocumented layers (vandaar de 'Nt' prefix), en houdt in dat het OS op een object free wacht, een semaphore. Vanuit VB heb je daar geen schuld aan, de components die je aanroept gebruiken niet kosjere code.

donderdag 4 juli 2002 21:36

Acties:

farlane

Dat klopt, maar je zou eventueel wel kunnen zien van waaruit die wait getriggered wordt. (Als je call stack volledig genoeg is.

)

Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.

vrijdag 5 juli 2002 11:12

Acties:

Verwijderd

Topicstarter

Na veel testen en schelden ben ik tot de volgende conclusie gekomen ... De dll moet dynamisch ingeladen worden ... Het betreft hier een standaard dll (dus geen ActiveX) ... Nu weet ik alleen niet hoe dit in VB moet ... Ik weet, LoadLibrary, GetProcAddress, FreeLibrary ... Helaas geeft GetProcAddress een pointer terug die ik weer niet kan verwerken ... Verder weet ik niet hoe ik de functie die ik dynamisch in wil laden moet declareren ... Ik dacht dat ik gewoon een type kon maken waarin iets stond in de trand van:
Type TDeClConnect as Function( DIM protocol As String ...
Dit kan dus niet ... Ik zou dus graag een voorbeeldje hebben hoe je een dll dynamisch inlaadt binnen VB ...

vrijdag 5 juli 2002 12:05

Acties:

Verwijderd

Je kunt de functie in de DLL gewoon definieren net als functies in bv kernel32.dll, in VB. Dan roep je die functie aan en VB laadt dan de DLL voor je in. Geen enkele DLL hoeft dynamisch ingeladen te worden in windows, want LoadLibrary + functionmapping is idem als static linked dll's die door win32 worden ingeladen.

Voor voorbeelden mbt het mappen van dll functies in VB kun je de VB docs raadplegen.

vrijdag 5 juli 2002 13:15

Acties:

Verwijderd

Topicstarter

Als dat hetzelfde is, waarom gaat het dan fout ??? Het is echt wel wat anders als ik de dll pas inlaadt op het moment dat ik dat wil en vrijgeef op het moment dat ik dat wil dan dat ding static declareren ... Ik moet dus een voorbeeld hebben hoe ik een dll dynamisch inlaadt ... En dit moet toch mogelijk zijn (dll = Dynamic Linked Library, toch

) ... Dus graag een voorbeeldje hiervan ...

vrijdag 5 juli 2002 13:33

Acties:

Verwijderd

Op vrijdag 05 juli 2002 13:15 schreef Norrit het volgende:
Als dat hetzelfde is, waarom gaat het dan fout ??? Het is echt wel wat anders als ik de dll pas inlaadt op het moment dat ik dat wil en vrijgeef op het moment dat ik dat wil dan dat ding static declareren ... Ik moet dus een voorbeeld hebben hoe ik een dll dynamisch inlaadt ... En dit moet toch mogelijk zijn (dll = Dynamic Linked Library, toch ) ... Dus graag een voorbeeldje hiervan ...

Mja, no offence, maar er is echt geen verschil wanneer je een library met LoadLibrary() inlaadt en allemaal functionpointers aanmaakt of dat je dat windows laat doen door static linking. In VB KUN je niet static linken met ee C-style DLL, dus hoe jij dat denkt te doen is me niet duidelijk. Je kunt alleen COM references opgeven.

In de docs staan veel examples mbt het aanroepen van kernel32.dll routines, dus die ga ik je echt niet voorkauwen.