locked
Winsock-Verbindung schlägt unter Vista fehl, wenn Anwendung mit normalen Benutzerrechten ausgeführt wird.

    Frage

  • Unsere Client-Server Applikation funktioniert auf Windows XP und Windows Server 2003/2008 problemlos, aber unter Vista gibt es Probleme beim Herstellen der Winsock-Verbindung.
     
    Auf unseren Entwickler-Systemen mit Vista SP2 64bit kann die Winsock-Verbindung nur hergestellt werden, wenn man den Client unter Administratorrechten startet. Unter normalen Benutzerrechten schlägt die Verbindung fehl.

    Auf einer frisch aufgesetzten VM mit Vista SP2 64bit funktioniert die Winsock-Verbindung auch mit normalen Benutzerrechten.

    - Virenscanner ist auf beiden Systemen der gleiche.
    - Windows Firewall ist auf beiden Systemen deaktiviert (macht aber auch keinen Unterschied).

    Welche Konfiguration könnte hier den Unterschied machen?
    Wo fange ich an zu suchen?
    Welche Tools könnten helfen?

    Danke für jeden Tipp!

    Heiko
    Mittwoch, 17. Juni 2009 11:26

Antworten

  • Mit trustinfo steht im Task-Manager Virtualisierung = Deaktiviert
    ohne trustinfo mit elevated rights steht dort Virtualisierung = Nicht zugelassen
    ohne trustinfo mit normalen Rechten steht dort Virtualisierung = aktiviert

    Der Fehler liegt wohl in unserem Code (wie oben beschrieben). Ich habe es auch schon mit einer kleinen Änderung getestet und jetzt klappts auch mit normalen Benutzerrechten.

    Aber schön, dass wir das mit dem trustinfo-manifest mal geklärt haben. :-)


    Gruß
    Heiko
    Dienstag, 23. Juni 2009 12:01

Alle Antworten

  • Gibt der Aufruf der socket-Funktion bei Dir auch WSAEPROVIDERFAILEDINIT zurück?
    Samstag, 20. Juni 2009 14:05
  • Hat die Anwednung ein Vista Manifest?
    Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de
    Montag, 22. Juni 2009 07:45
  • Das Manifest sieht so aus:


    <assembly xmlns="urn:schemas-microsoft-com:asm.v1"
    manifestVersion="1.0">
      <assemblyIdentity version="1.0.0.0" processorArchitecture="X86"
      name="fooApp" type="win32"></assemblyIdentity>
      <description>This is the client application for
      our app.</description>
      <dependency>
        <dependentAssembly>
          <assemblyIdentity type="win32"
          name="Microsoft.Windows.Common-Controls" version="6.0.0.0"
          processorArchitecture="X86" publicKeyToken="6595b64144ccf1df"
          language="*"></assemblyIdentity>
        </dependentAssembly>
      </dependency>
      <dependency>
        <dependentAssembly>
          <assemblyIdentity type="win32" name="Microsoft.VC80.CRT"
          version="8.0.50727.762" processorArchitecture="x86"
          publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
        </dependentAssembly>
      </dependency>
      <dependency>
        <dependentAssembly>
          <assemblyIdentity type="win32" name="Microsoft.VC80.MFC"
          version="8.0.50727.762" processorArchitecture="x86"
          publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
        </dependentAssembly>
      </dependency>
      <dependency>
        <dependentAssembly>
          <assemblyIdentity type="win32" name="Microsoft.VC80.OpenMP"
          version="8.0.50727.762" processorArchitecture="x86"
          publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
        </dependentAssembly>
      </dependency>
      <dependency>
        <dependentAssembly>
          <assemblyIdentity type="win32" name="Microsoft.VC80.CRT"
          version="8.0.50608.0" processorArchitecture="x86"
          publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
        </dependentAssembly>
      </dependency>
    </assembly>


    Was ist ein "Vista Manifest"?
    Montag, 22. Juni 2009 12:39
  • Nein das ist kein Vista Manifest!
    Damit wird Dein Programm in jedem Fall mit Virtualisierung gestartet.
    Siehe hier und die weiterführenden Links:
    http://blog.m-ri.de/index.php/2006/12/12/vista-und-die-notwendigkeit-eines-manifestes-fur-die-uac/

    Siehe auch:
    http://blog.m-ri.de/index.php/2007/02/15/uac-trustinfo-manifest-in-ein-vc-2005-sp1-projekt-einfugen/

    Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de
    Montag, 22. Juni 2009 13:06
  • Ich habe jetzt also den trustinfo-block eingefügt:

    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    	<assemblyIdentity version="1.0.0.0" processorArchitecture="X86" name="ourApp" type="win32"/>
    	<description>This is the client application for ourApp.</description>
    	<dependency>
    		<dependentAssembly>
    			<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="X86" publicKeyToken="6595b64144ccf1df" language="*"/>
    		</dependentAssembly>
    	</dependency>
    	<dependency>
    		<dependentAssembly>
    			<assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.762" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"/>
    		</dependentAssembly>
    	</dependency>
    	<dependency>
    		<dependentAssembly>
    			<assemblyIdentity type="win32" name="Microsoft.VC80.MFC" version="8.0.50727.762" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"/>
    		</dependentAssembly>
    	</dependency>
    	<dependency>
    		<dependentAssembly>
    			<assemblyIdentity type="win32" name="Microsoft.VC80.OpenMP" version="8.0.50727.762" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"/>
    		</dependentAssembly>
    	</dependency>
    	<dependency>
    		<dependentAssembly>
    			<assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50608.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"/>
    		</dependentAssembly>
    	</dependency>
    	<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    		<security>
    			<requestedPrivileges>
    				<requestedExecutionLevel level="asInvoker"/>
    			</requestedPrivileges>
    		</security>
    	</trustInfo>
    </assembly>

    Das ändert aber leider nichts am (Fehl-)Verhalten.

    (btw: Leider führen einige der Links auf Deiner Blog-Seite ins MS-Nirvana.)

    Warum funktioniert die Verbindung auf einem System und nicht auf dem anderen (beides Vista SP2)?
    Dienstag, 23. Juni 2009 07:24
  • Nein. Der socket-Aufruf liefert ein gültiges Handle.

    Erst später in dieser Schleife

    nResult = pS->Connect(server, nPort); 
    // hier passiert der Aufruf 	connect(m_hSocket, SOCKADDR*)&sockAddr, sizeof(sockAddr))
    
    while ( nResult==WSAEWOULDBLOCK ) { // Wait for Connect-Notification
    	Wnd_DoOneMessage_WaitFor();
    	nResult = pS->GetConnectionState();
    }
    


    wird der ConnectionState ungültig (WSAENOTCONN). Oder vielmehr bleibt er auf "nicht verbunden".

    Das könnte daran liegen, dass in der Funktion Wnd_DoOneMessage_WaitFor() eine Message ankommt, die evtl. nicht richtig verarbeitet wird:
    Der Wert von MSG::message ist 799 (0x031F). Die einzige Definition einer Message, die ich gefunden habe ist: WM_DWMNCRENDERINGCHANGED. Das klingt für mich danach, dass hier der Desktop-Windows-Manager  (DWM.exe) mitteilen will, dass sich das Rendering der Non-Client-Area geändert hat.

    Und da unterscheidet sich das Verhalten zwischen normalen und erhöhten Benutzerrechten: Mit erhöhten Benutzerrechten kommt die Message nicht.

    Ich habe mir nochmal unseren Code angesehen und es schwant mir, dass er einfach zu sensibel darauf reagiert, dass da evtl. noch andere unerwartete Messages ankommen.

    Kann man diese Message durch irgendeine Konfigurationseinstellung (z.B. Sicherheitsrichtlinie) unterdrücken? Es ist immer noch die Frage offen, warum es auf einem anderen Vista-System funktioniert.
    Dienstag, 23. Juni 2009 08:50
  • Und im Task-Manager steht hinter dem Tsak bei Virtualisierung ein Deaktiviert?
    OK. War mal so ein Verdacht, das evtl. die Virtualisierung hier einen Streich spielt.

    Warum es auf einem funktioniert und auf dem anderen nicht, kann ich Dir nicht sagen.
    Aber grundsätzlich wäre es hilfreich wenn Du uns den Erro Code nennen köntest.
    Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de
    Dienstag, 23. Juni 2009 08:53
  • Mit trustinfo steht im Task-Manager Virtualisierung = Deaktiviert
    ohne trustinfo mit elevated rights steht dort Virtualisierung = Nicht zugelassen
    ohne trustinfo mit normalen Rechten steht dort Virtualisierung = aktiviert

    Der Fehler liegt wohl in unserem Code (wie oben beschrieben). Ich habe es auch schon mit einer kleinen Änderung getestet und jetzt klappts auch mit normalen Benutzerrechten.

    Aber schön, dass wir das mit dem trustinfo-manifest mal geklärt haben. :-)


    Gruß
    Heiko
    Dienstag, 23. Juni 2009 12:01