[C++] Applicatie crasht bij runnen buiten Visual Studio

[Wouter]

Ik zit momenteel met een eigenaardig probleem,
een probleem dat ik nog nooit eerder ben tegengekomen bij het ontwikkelen van applicaties.

Ik ben bezig met een 3d applicatie, die gebruik maakt van OpenSG (scenegraph systeem gebaseerd op opengl), maar de vraag die ik heb is een stuk algemener:

De applicatie werkt perfect wanneer ik deze vanuit visual studio start (in debug en release mode)
Wanneer ik de executable in de /release of /debug directory start, crasht de applicatie op een dll van OpenSG (... has encountered a problem and needs to close).

De applicatie heeft geen commandline argumenten nodig, wel worden er bestanden ingeladen,
maar deze staan in dezelfde directory als de executable... en zelfs als de bestanden niet gevonden zouden kunnen worden, crasht de applicatie hier niet door.

Mijn vraag is dan ook; wat is nu precies het verschil tussen het starten van een applicatie vanuit VS en het starten van de executable buiten VS?
Naar mijn weten is het enige verschil de working directory en de command arguments, maar blijkbaar niet...

Iemand die hier iets zinnigs over kan zeggen?

[Sebazzz]

Visual Studio draait de applicatie binnen een 'hosting process'.
Probeer eens een niet-debug build te maken, crasht ie ook?

[Wouter]

Sebazzz schreef op woensdag 27 augustus 2008 @ 14:46:
Visual Studio draait de applicatie binnen een 'hosting process'.
Probeer eens een niet-debug build te maken, crasht ie ook?

ja

[edeboeck]

En heb je al geprobeerd om het in een installer te gieten (en vervolgens te installeren en uit te voeren)?

[Wouter]

Nee, maar dat heb ik nog nooit gedaan; dus dat maakt het geheel alleen maar complexer

Ik snap niet waarom dat uit zou moeten maken,
alle benodigde dependencies zijn aanwezig, anders zou ie vanuit visual studio ook niet draaien

Als ie een dll niet zou kunnen vinden, krijg je daar een specifieke foutmelding van,
ik probeer gewoon te begrijpen wat nu het verschil kan zijn tussen draaien vanuit VS en daarbuiten.

[ Voor 28% gewijzigd door Wouter op 27-08-2008 14:53 ]

[farlane]

Heb je de dll ook zelf gecompileerd of heb je alleen een binary?

[edeboeck]

ik probeer gewoon te begrijpen wat nu het verschil kan zijn tussen draaien vanuit VS en daarbuiten.

ik denk spontaan aan de gebruikersrechten waarmee het wordt uitgevoerd ...
Daarnaast is de opmerking van farlane terecht imho: ben je 100% zeker dat die dll correct werkt?

[Wilke]

Geheugenlocaties kunnen anders zijn, klinkt als memory corruption die soms wel en soms niet tot een crash leidt.

Bv. heb je misschien geheugen "by reference" (pointer) doorgegeven aan die DLL en vervolgens het geheugen gefree()'ed terwijl de DLL dus niet een kopie van de data gebruikt? Dan kun je zoiets krijgen afhankelijk van of het OS het geheugen "echt" herclaimed heeft of niet.

[ Voor 55% gewijzigd door Wilke op 27-08-2008 15:11 ]

[geforce5_guy]

Wouter schreef op woensdag 27 augustus 2008 @ 14:52:
Nee, maar dat heb ik nog nooit gedaan; dus dat maakt het geheel alleen maar complexer

Ik snap niet waarom dat uit zou moeten maken,
alle benodigde dependencies zijn aanwezig, anders zou ie vanuit visual studio ook niet draaien

Als ie een dll niet zou kunnen vinden, krijg je daar een specifieke foutmelding van,
ik probeer gewoon te begrijpen wat nu het verschil kan zijn tussen draaien vanuit VS en daarbuiten.

Visual studie maakt een afgeschermt stuk geheugen op je computer waarin je applicatie draait. Hij zorgt er dus voor dat je dependencies beschikbaar hebt.
Dus als je het als een normale app wilt draaien zonder visual studio dan vraag hij aan windows ik wil een bepaalde dll gebruiken. Als windows hem neit ken zal je applicatie niet werken.

Het kan dus zijn dat windows de dll niet kent.

[Wilke]

^ maar als het programma crasht *in* de code van die DLL zal dat niet zo zijn (geen idee of dat zo is, alleen). Kun je het window van de foutmelding eens posten dan wordt het misschien iets duidelijker.

[geforce5_guy]

Misschien om een log file te maken die je programma gebruikt om te loggen wat hij doet. Op die manier kan je zien vanaf welk punt het verkeerd gaat.

Dit werkt alleen als hij uberhaubt iets doet uitraard.

[.oisyn]

Het feit dat je app niet crashed in de debugger betekent niet dat je app goed is. Het betekent echter dat de symptomen niet tevoorschijn komen. De oorzaak kan zoiets simpels zijn als een ongeinitialiseerde variabele.

Maar goed, het lijkt me natuurlijk vrij logisch dat de eerstvolgende stap die je nu moet doen is je app buiten VS runnen, die laat crashen, en vervolgens de debugger attachen om te kijken wat er aan de hand is

[Invisible_man]

Met een C++ applicatie (met zowel .exe's als dll's) had ik een soortgelijk probleem. Dit probleem kwam alleen bij duo-core en hyperthreading pc's voor (tegenwoordig dus vrijwel alle pc's). Dit was op te lossen met een commandline tooltje (imagecfg.exe) wat forceerd dat een dll of exe op één core wordt uitgevoerd. Het betrof hier overigens een applicatie gemaakt met de antieke VS6.0, ik weet niet welke versie jij gebruikt? Het kan natuurlijk ook nog zo zijn dat die dll in een oudere visual studio gemaakt was.

[Soultaker]

Is het niet iets simpels als dat bepaalde bestanden niet gevonden worden? Als ik het me goed herinner wordt een executable als "Project\Release\Project.exe" uitgevoerd vanuit de directory "Project", terwijl als je er in Explorer op klikt, hij gewoon in de directory "Project\Release" begint. Misschien dat je dan bepaalde files niet kan open o.i.d.?

[Zoijar]

Ik denk dat je misschien twee verschillende opensg dll's op je systeem hebt staan. In visual studio wordt het executable path eerst afgezocht (of de library include?) en wordt ge correcte dll gebruikt, maar als je commandline opstart is je path anders en wordt er een oude dll geladen die crashed. Althans, dat zou zo kunnen zijn. Ik had het laatst met Qt.

[leuk_he]

Visual studio draait wellicht als administrator (vista. met UA enabled?)

en kun je als het "needs to close" niet de debugger attachen? En ook aan eendraaien proces kun je evt de debugger van visual studio attachen.

[MSalters]

Voor alle duidelijkheid: Als je een programma opstart vanuit Visual Studio, dan is dat een apart process los van Visual Studio zelf. Soultakers suggestie is een behoorlijk goede aanname; bij het opstarten vanuit Visual Studio is de Current Working Directory expliciet gezet (zie solution properties)

DLL problemen in het algemeen zijn het makkelijkst op te lossen met Dependency Walker. Je kunt Dependency Walker log gebruiken op een losse EXE, en in profiling mode kun je een proces startup tracen. Dankzij de command line van Dependency Walker kun je't ook gebruiken om een proces te tracen dat vanuit Visual Studio is opgestart. Verander de exceutable die je wil starten in depends.exe; geef als argumenten de Dependency Walker argumenten op inclusief de EXE die je wil laten tracen.

[Coltrui]

Ooit een gelijkaardig probleem gehad met C++ na een update van DirectX die wezenlijk verschilde van de SDK die gebruikt werd door de debugger...

O en een linkje dat het lezen waard is...

[Wouter]

Excuses voor de late reaktie, ik heb me even met andere dingen bezig moeten houden en kom nu weer aan dit probleem toe

farlane schreef op woensdag 27 augustus 2008 @ 15:00:
Heb je de dll ook zelf gecompileerd of heb je alleen een binary?

Ik heb alleen een binary.

Wilke schreef op woensdag 27 augustus 2008 @ 15:08:
Geheugenlocaties kunnen anders zijn, klinkt als memory corruption die soms wel en soms niet tot een crash leidt.

Bv. heb je misschien geheugen "by reference" (pointer) doorgegeven aan die DLL en vervolgens het geheugen gefree()'ed terwijl de DLL dus niet een kopie van de data gebruikt? Dan kun je zoiets krijgen afhankelijk van of het OS het geheugen "echt" herclaimed heeft of niet.

Het is niet soms wel en soms niet crashen. Vanuit VS crasht het nooit. Buiten VS altijd.

edeboeck schreef op woensdag 27 augustus 2008 @ 15:04:
[...]
ik denk spontaan aan de gebruikersrechten waarmee het wordt uitgevoerd ...
Daarnaast is de opmerking van farlane terecht imho: ben je 100% zeker dat die dll correct werkt?

Ben gewoon administrator. De DLL werkt correct, vanuit VS wordt dezelfde DLL gebruikt.

geforce5_guy schreef op woensdag 27 augustus 2008 @ 15:09:
[...]
Visual studie maakt een afgeschermt stuk geheugen op je computer waarin je applicatie draait. Hij zorgt er dus voor dat je dependencies beschikbaar hebt.
Dus als je het als een normale app wilt draaien zonder visual studio dan vraag hij aan windows ik wil een bepaalde dll gebruiken. Als windows hem neit ken zal je applicatie niet werken.

Het kan dus zijn dat windows de dll niet kent.

Als de applicatie een DLL niet kan vinden, dan krijg je hier een specifieke melding van. Wat bijvoorbeeld gebeurt als ik de DLL even een andere naam geef. Hij vind hem dus wel.

.oisyn schreef op woensdag 27 augustus 2008 @ 15:28:
Het feit dat je app niet crashed in de debugger betekent niet dat je app goed is. Het betekent echter dat de symptomen niet tevoorschijn komen. De oorzaak kan zoiets simpels zijn als een ongeinitialiseerde variabele.

Maar goed, het lijkt me natuurlijk vrij logisch dat de eerstvolgende stap die je nu moet doen is je app buiten VS runnen, die laat crashen, en vervolgens de debugger attachen om te kijken wat er aan de hand is

Ga ik proberen

Invisible_man schreef op woensdag 27 augustus 2008 @ 15:41:
Met een C++ applicatie (met zowel .exe's als dll's) had ik een soortgelijk probleem. Dit probleem kwam alleen bij duo-core en hyperthreading pc's voor (tegenwoordig dus vrijwel alle pc's). Dit was op te lossen met een commandline tooltje (imagecfg.exe) wat forceerd dat een dll of exe op één core wordt uitgevoerd. Het betrof hier overigens een applicatie gemaakt met de antieke VS6.0, ik weet niet welke versie jij gebruikt? Het kan natuurlijk ook nog zo zijn dat die dll in een oudere visual studio gemaakt was.

Ik hou het achter de hand als last resort. Ik gebruik VS8, DLL is ook daarmee gecompileerd (volgens de website).

Soultaker schreef op woensdag 27 augustus 2008 @ 15:41:
Is het niet iets simpels als dat bepaalde bestanden niet gevonden worden? Als ik het me goed herinner wordt een executable als "Project\Release\Project.exe" uitgevoerd vanuit de directory "Project", terwijl als je er in Explorer op klikt, hij gewoon in de directory "Project\Release" begint. Misschien dat je dan bepaalde files niet kan open o.i.d.?

Dit heb ik al uitgesloten. Het niet kunnen vinden van bestanden wordt sowieso gewoon afgevangen en leidt niet tot een crash.

Zoijar schreef op woensdag 27 augustus 2008 @ 17:09:
Ik denk dat je misschien twee verschillende opensg dll's op je systeem hebt staan. In visual studio wordt het executable path eerst afgezocht (of de library include?) en wordt ge correcte dll gebruikt, maar als je commandline opstart is je path anders en wordt er een oude dll geladen die crashed. Althans, dat zou zo kunnen zijn. Ik had het laatst met Qt.

Heb maar 1 versie.

leuk_he schreef op woensdag 27 augustus 2008 @ 17:14:
Visual studio draait wellicht als administrator (vista. met UA enabled?)

en kun je als het "needs to close" niet de debugger attachen? En ook aan eendraaien proces kun je evt de debugger van visual studio attachen.

Draai XP. En ga inderdaad nu even proberen te debuggen als ie crasht.

Coltrui schreef op donderdag 28 augustus 2008 @ 16:15:
Ooit een gelijkaardig probleem gehad met C++ na een update van DirectX die wezenlijk verschilde van de SDK die gebruikt werd door de debugger...

O en een linkje dat het lezen waard is...

Ik ga het even doorlezen, thanks

[Wouter]

Wilke schreef op woensdag 27 augustus 2008 @ 15:13:
^ maar als het programma crasht *in* de code van die DLL zal dat niet zo zijn (geen idee of dat zo is, alleen). Kun je het window van de foutmelding eens posten dan wordt het misschien iets duidelijker.

AppName: opensgnav.exe AppVer: 0.0.0.0 ModName: osgbase.dll
ModVer: 0.0.0.0 Offset: 00049929

Dat is een DLL van OpenSG


Als ik kies om te debuggen, krijg ik de foutmelding:

Unhandled exception at 0x10049929 in OpenSGNav.exe: 0xC0000005: Access violation writing location 0x00000034.

[.oisyn]

Je hebt toch wel een callstack? Of gebeurt het al voordat je main() wordt aangeroepen?

[Wouter]

Ja het gaat fout in die OSGBase.dll,
daar heb ik alleen een binary van, dus kan niet de code zien waar het fout gaat.

Callstack zegt:

> OSGBase.dll!10049929()
> OpenSGNav.exe!0040ce0b()

[.oisyn]

Maakt in principe niet uit, zolang je maar debug symbols hebt van je eigen applicatie hebt. Run je hier überhaupt wel een debug build? Ik gok van niet anders had ik wel wat CRT functies op de top van je callstack zien staan...

[Wouter]

Opgelost. Heb de code nog eens heel goed doorgenomen...

.oisyn schreef op woensdag 27 augustus 2008 @ 15:28:
De oorzaak kan zoiets simpels zijn als een ongeinitialiseerde variabele

Er bleek 1 boolean niet op 'false' te worden geinitialiseerd,
vanuit VS leverde dit geen problemen op; daarbuiten wel.

Stomme fout, sorry voor het verspillen van jullie tijd