Results 1 to 14 of 14

Thread: Delphi DLL met IIS op een 64-bit variant

  1. #1

    Delphi DLL met IIS op een 64-bit variant

    Geachte Delphi experts,

    Is het mogelijk dat een Delphi DLL op een W8 IIS een extra installatie nodig heeft om te kunnen draaien op 64 bit.

    Ik heb een web service ontwikkeld met MARS Curiosity en werkt uitsteking, op een 32-bit windows 7. Nu heb ik een Windows Server R2 2012 (64-bit) en nu krijg ik een op een POST-method de gevreesde 500 internal server error. Terwijl een simpele 'hello world' response wel terug krijg en ook specifieke antwoorden (en andere post methods naar een database, die werken wel). In de service kan ik de error Post methode niet overslaan want die valideert mijn gebruiker.

    Informatie is zeer gewenst en hoop dat er iemand is die er meer van weet.

    Extra informatie
    - .Net framework en framework64 zitten inde iSAPI-filters
    - Functie bemachtiging op handlerstoewijzing staat 'uitvoeren' aan
    - Serverhoogte ISAPI modules en CGI modules staan op 'toestaan'
    - toepassingsgroepen (.net v2.0) instellingen: pipeline: Geïntegreerd, 32-bit toepassingen inschakelen staat op 'True'

  2. #2
    http://docwiki.embarcadero.com/RADSt...kyo/en/OpenSSL

    Het is een Cannot load openSSL library melding maar als ik de des betreffende dll's van de download link haal dan werkt het nog steeds niet geheel, of ja..... ik heb 2 machines waarvan elk de zelfde instellingen maar op een 64bit Windows werkt hetwel, en de ander blijft de error omhoog komen. Wordt er een beetje gek van op deze manier

  3. #3
    Welke dll's heb je ingehaald en waar geen je ze neergezet?

    Duidelijk is dat één van je 64 bit machines de 64 bit openssl dll's al in zijn path heeft staan.

  4. #4
    Waar zou ik de path dan kunnen instellen?

    De dll's gaan in hun desbetreffende aangegeven mappen van de site in mijn reactie, of wel:

    System32 folder is for 64-bit files only.
    SysWOW64 folder is for 32-bit files only.

    Van de link heb ik optie 1 gedaan en de Win64 OpenSSL v1.0.2L Light variant. Hiervan heb ik de files libeay32 en ssleay32 in de map geplaatst. Dit was genoeg om het op 1 64-bit W werkend te krijgen. De ander jammer genoeg niet.

    Maar als ik kijk op deze site: http://www.indyproject.org/Sockets/f...rWin64.en.aspx
    Dan moet mijn dll in mijn project folder in plaats van de shared Sys32 variant.

    Deze site heb ik ook bekeken maar niks van af gehaald: https://indy.fulgan.com/SSL/

  5. #5
    Path is niet iets dat je zelf instelt maar dat het OS gebruikt om je DLL's te vinden.

    Het zou kunnen zijn dat op de machine waarop het niet werkt in het path een 32 bit variant staat en als het OS die dan als eerste tegenkomt dan zal het laden daarvan mislukken.

    Je kunt dit op twee manieren oplossen:

    - Zorg ervoor dat de 64bit DLL's in je programma directory staat. Dan werkt het altijd. Je eigen directory is n.l. het eerste waar het OS naar kijkt voor het "path" af te zoeken. Ik zet ook gewoon de goede dll's in de eigen programma directory maar sommige "puristen" zeggen dat je hem in de system-directory moet zetten.

    - Zoek uit welke 32bit DLL voor problemen zorgt (sowieso verstandig)
    Dit kun je doen door een command prompt te openen (cmd.exe) en path + enter in te tikken.
    Nu zie je een path en dan zou je moeten kijken welke paden er allemaal in staan.
    Zoek al die paden af op zoek naar een libeay32.dll en kijk dan of dat een 32 of 64bit versie is.
    Hij zou alleen in System32 mogen staan.

    Gelukkig hoef je dit niet handmatig te doen maar is er een utility where standaard in Windows.
    Dus doe dit:
    where /t libeay32.dll
    where /t ssleay32.dll
    Controleer of de grootte en datum kloppen met de 64bit versie.
    Nogmaals... alleen die van System32 zou zichtbaar mogen zijn (of degene in de directory waarin je dit start).

    Overigens kun je gewoon die van https://indy.fulgan.com/SSL/ pakken. Dat is de algemeen geaccepteerde download site voor openssl.

  6. #6
    Hopelijk dat het naar mijn ding probleem leidt en de oplossing gevonden kan worden. Ik zal dit zsm gaan proberen.

    Dankuel voor de geweldige reactie.

  7. #7
    Ik heb het geprobeerd maar ik heb nu wel mijn twijfels.

    - Het werkt niet als ik het in mijn programma directory plaats. (mogelijke sharing rechten niet goed, nog niet gekeken)

    Via indy.fulgan de laatste variant L gedownload voor zowel 86 en 64.
    - ssleay32 en libeay32 van de 64-bit files werken niet in de system32 of syswow64
    - tevens als de 32-bit files werken niet in de system32 (op een 64bit windows, werkt wel op een 32bit versie)

    - 32-bit files werken wel in de syswow64, maar
    met de command where /t libyea32.dll krijg ik 2 resultaten dat die is geplaats in zowel syswow64 en system32.

    Gezien rvk duidelijk maakte dat het alleen in system32 zichtbar moet zijn, begin ik me nu af te vragen of wat er momenteel gebeurd wel echt de bedoeling is.

  8. #8
    Ja, dat zou niet mogen. De where zoekt je path af en die zou alleen System32 tegen mogen komen.

    Even getest (zie onder, even getest met xwreg.dll want ik heb de openssl niet in c:\windows staan).

    Vraagje... hoe is je path als je path + enter drukt in een cmd.exe?
    Daar zou n.l. geen C:\Windows\SysWOW64 tussen mogen staan !!!

    Code:
    C:\>dir c:\windows\system32\xwreg.dll
     Volume in drive C is OS
     Volume Serial Number is E031-9825
    
     Directory of c:\windows\system32
    
    18-03-2017  22:57           117.760 xwreg.dll
                   1 File(s)        117.760 bytes
                   0 Dir(s)  47.579.328.512 bytes free
    
    C:\>dir c:\windows\syswow64\xwreg.dll
     Volume in drive C is OS
     Volume Serial Number is E031-9825
    
     Directory of c:\windows\syswow64
    
    18-03-2017  22:58            99.840 xwreg.dll
                   1 File(s)         99.840 bytes
                   0 Dir(s)  47.579.328.512 bytes free
    
    C:\>where /t xwreg.dll
        117760   18-03-2017      22:57:00  C:\Windows\System32\xwreg.dll
    Dus alleen de xwreg.dll in C:\Windows\System32 wordt gevonden en niet die in SysWOW64.

    Ik denk dat dan ook jouw openssl dll's uit de SysWOW64 gepakt worden in je 64 bit programma.

    Overigens kun je natuurlijk gewoon al die opensll dll's even verwijderen en alleen in je programma dir zetten en kijken of het dan wel werkt.

  9. #9
    Ik heb geprobeerd te zoeken naar wat u bedoelt maar ben niet geheel uit gekomen.

    Mogelijk dat een foto meer zegt dan mijn woorden.


    Click image for larger version. 

Name:	image001.png 
Views:	155 
Size:	12.0 KB 
ID:	7569

    Als ik de dll's weghaal dan kan ik ook geen gebruik maken van mijn webservice, en dan ga ik toch even opnieuw proberen om de dll's in de programma dir te zetten.
    Ik zal het even gaan bekijken

  10. #10
    overigens ben ik ook wel benieuwd naar de mogelijk schade van wat er bij mij momenteel voorkomt?

  11. #11
    Hee, dat is heel raar.
    De where moet je inderdaad in de root C:\ uitvoeren zodat alleen het path afgezocht wordt.
    Als je hem in C:\Windows\SysWOW64 uitvoert dan is het logisch dat de file daar ook gevonden wordt.

    Maar in C:\ zou de where ook die in C:\Windows\System32 moeten vinden en dat gebeurd niet, raar...

    Tevens lijken die libeay32.dll dezelfde te zijn. Dat zou niet mogen. (zeker niet als je dit in cmd.exe 64 bit uit voert).

    En dan in C:\Windows\System32 vindt die where de libeay32.dll helemaal niet...

    Hoe ziet je path er nu uit ????

    Ik zou de libeay32.dll en ssleay32.dll helemaal uit de C:\Windows\SysWOW64 en C:\Windows\System32 halen en alleen in je programma directory neerzetten. Dat zou moeten werken. (mocht je later een programma tegenkomen dat een probleem heeft met https dan kun je die altijd weer terugzetten)

    Als ik de dll's weghaal dan kan ik ook geen gebruik maken van mijn webservice
    Welke webservice. Want volgens mij maakt Microsoft zelf geen gebruik van deze dll's.
    Last edited by rvk; 08-Jun-17 at 12:46.

  12. #12
    Mijn eigen webservice die op IIS draait voor Authenticatie

    Het rare aan het verhaal is dat in de cmd screenshot die ik net postte, was alleen ssleay32 en libeay32 in de SysWow64 directory. Het is logisch dat er in System32 niks kan vinden want daar staat geen van beide dll's, waarom de where /t daar anders overdenkt, geen idee.

    ik begin steeds meer te twijfelen of wat ik nu doe wel de juiste aanpak is, alleen het moet wel gaan werken in een zekere vorm.

    De huidige situatie is alsvolgt:
    Een IIS draait op een intern IP adres die onder een Delphi gemaakte 'dll',
    Ik heb geprobeerd om de libeay32 en ssleay32 in de IIS inetpub/wwwroot en zijn website map gezet maar dat zorgde niet dat de error 'Cannot load openSSL library' weg gaat jammer genoeg.

    Functionele situatie op een 64 bit windows:
    is via Https te benaderen voor authenticatie, maar als het local niet werkt, dan werkte dat al helemaal niet.

    Het ergste gedeelte vind ik het feit dat op een 32-bit windows versie ik geen enkel probleem heb met het draaien van de OpenSSL dll's in hun system32 directory. Daar werkt het prima.

    Mss om te kijken kan ik een nieuwe virtuele Computer aanmaken met een clean 64-bit installatie. Ik zie het mezelf er wel vooraan om het ergens toch fout te hebben gedaan en daarom alle rare dingen te krijgen, jammer genoeg.

  13. #13
    Quote Originally Posted by GHofman View Post
    Het rare aan het verhaal is dat in de cmd screenshot die ik net postte, was alleen ssleay32 en libeay32 in de SysWow64 directory. Het is logisch dat er in System32 niks kan vinden want daar staat geen van beide dll's, waarom de where /t daar anders overdenkt, geen idee.
    Ja, maar als er in System32 niet de 64bit versies staan kan die ook niet gevonden worden.

    Je moet dit ook allemaal controleren met een 64 bit programma (cmd.exe of in de explorer) want als je met een 32bit programma gaat kijken in C:\Windows\System32 kijk je eigenlijk in C:\Windows\SysWOW64 (zonder dat je het weet )

    Een IIS draait op een intern IP adres die onder een Delphi gemaakte 'dll',
    Ik heb geprobeerd om de libeay32 en ssleay32 in de IIS inetpub/wwwroot en zijn website map gezet maar dat zorgde niet dat de error 'Cannot load openSSL library' weg gaat jammer genoeg.
    En is dat een 32bit dll of een 64 bit dll? Heb je dan de 32bit openssl dll's of de 64bit dll's daarbij gezet?

    Het ergste gedeelte vind ik het feit dat op een 32-bit windows versie ik geen enkel probleem heb met het draaien van de OpenSSL dll's in hun system32 directory. Daar werkt het prima.
    Nee, de 32 bit KAN niet in die C:\Windows\System32 kijken. Als die dat doet dan krijgt ie de C:\Windows\SysWOW64 bestanden !!

    De situatie moet dus als volgt zijn:
    - Zet de 32 bit openssl in C:\Windows\SysWOW64 en de 64 bit openssl in C:\Windows\System32 en niets in je programma directory

    - Zet de 64 bit openssl in je programma directory (bij je 64 bit programma) en dan worden die gebruikt. Wat in het path staat zou dan niet meer uit mogen maken.

    Wat was je path nou ??

  14. #14
    En is dat een 32bit dll of een 64 bit dll? Heb je dan de 32bit openssl dll's of de 64bit dll's daarbij gezet?
    Het is een 32bit dll die daar draait. De beredenering was wegens dat IIS 32bits toepassingen op true staat en daarom ook de 32bit openssl dll's erbij gezet heb.

    De 64bit dll heb ik wel een aantal keren geprobeerd te gebruiken (32-bits toepassingen op false).

    Ik ga de situatie die u heeft neergezet volgen.

    Wat was je path nou ??
    Click image for larger version. 

Name:	image001.png 
Views:	201 
Size:	12.0 KB 
ID:	7570

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •