none
Mon app.exe c++ ne fonctionne pas sous Windows 10. RRS feed

  • Question

  • Bonjour , 
    J'ai développé une application en langage de programmation c++, quand je souhaite la déployer sur une machine client avec comme OS : Windows 10 , une fenêtre apparaît " Le programme a cessé de fonctionner " pourtant sur une autre machine client 8.1 ça marche sans soucis.
    PS : J'ai bel et bien installé le vc_redistx84.Exe sur toutes les machines
    Ide: VS Enterprise 2015

    lundi 13 février 2017 16:55

Réponses

  • Pour résoudre le problème de compatibilité de mon application sur l'OS Windows 10 j'ai du cibler ce dernier à l'aide "l'app manifest"  

    Pour ce faire j'ai crée un fichier .xml contenant :

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
        <assemblyIdentity 
            type="win32" 
            name=SXS_ASSEMBLY_NAME
            version=SXS_ASSEMBLY_VERSION
            processorArchitecture=SXS_PROCESSOR_ARCHITECTURE
        />
        <description> my exe </description>
        <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
            <security>
                <requestedPrivileges>
                    <requestedExecutionLevel
                        level="asInvoker"
                        uiAccess="false"
                    />	
                </requestedPrivileges>
            </security>
        </trustInfo>
        <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"> 
            <application> 
                <!-- Windows 10 --> 
                <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
                <!-- Windows 8.1 -->
                <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
                <!-- Windows Vista -->
                <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/> 
                <!-- Windows 7 -->
                <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
                <!-- Windows 8 -->
                <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
            </application> 
        </compatibility>
    </assembly>

    En l'incluant dans un .rc et en changeant la propriété "Editeur de lien" => "Génération d'un manifeste" en
    NON (/MANIFEST:NO).

    Le problème "Application a cessé de fonctionner" n'apparaît plus.

    Pourriez-vous me clarifier les choses concernant l'intérêt de la génération du manifeste qui a permis de résoudre mon problème?
    Merci pour votre intervention @Paul Bacelar.

     

    mardi 14 février 2017 16:03
  • Sur la machine client on ne dispose pas de VS.
    L'application marche parfaitement sur 8.1 et versions antérieurs et pas pour le 10.

    Vous n'avez pas besoin d'avoir VS sur la machine du client.

    Il suffit de copier le ou les fichiers de dump là où un VS peut les ouvrir.

    Il y a assez d'information dans le dump pour récupérer les informations de débug du l'OS hôte client, même si VS est installé sur un OS qui n'a rien à voir. Il faut juste correctement configurer le serveur de symbole sous VS.

    P.S.: Il y a aussi pas mal de fichier texte en plus des fichiers de dump qui peuvent être lu sans VS, directement sur la machine client.

    Pour l'histoire du manifeste :

    Vos explications sont contradictoire, quelles sont les différences entre votre ressource et celles générées par le linker ?

    Vous n'avez peut-être juste que cacher le "vrai" problème ? => analyses des fichiers dump.

    Je ne suis même pas sûr que votre nouveau programme ait un "vrai" manifeste.

    Vous semblez vous mettre des œillères "c'est un problème de compatibilité". Mais, moi, je vois plus ce "problème" comme une chance de trouver un bug existant et voir Win10 comme un révélateur très pratique du problème.

    Les problèmes de compatibilité, c'est à posteriori, après une analyses, pas à priori.


    Paul Bacelar, Ex - MVP VC++


    mercredi 15 février 2017 13:11
    Modérateur

Toutes les réponses

  • N'oubliez pas d'utiliser un projet de déploiement pour créer le MSI de déploiement.

    Vous ne mentionnez aucune des actions permettant de s'assurer de la compatibilité de la plate-forme d'exécution, je suppose donc que vous y êtes allé comme un cow-boy, non ?

    Le plus simple, c'est de voir dans l'eventLog ce qui y est marqué, en utilisant l'EventViewer.


    Paul Bacelar, Ex - MVP VC++

    lundi 13 février 2017 17:05
    Modérateur
  • Comment faire pour examiner les données de l'EventViewer?
    Je n'ai pas pu assimiler ce qu'à pu donner le résultat.
    lundi 13 février 2017 20:53
  • Montrez ce qu'affiche l'EventViewer.

    Paul Bacelar, Ex - MVP VC++

    mardi 14 février 2017 11:03
    Modérateur
  • Récipient d’erreurs 116332016489, type 5
    Nom d’événement : BEX
    Réponse : Non disponible
    ID de CAB : 0

    Signature du problème : 
    P1 : ToolConversion.exe
    P2 : 0.0.0.0
    P3 : 58a1de98
    P4 : ToolConversion.exe
    P5 : 0.0.0.0
    P6 : 58a1de98
    P7 : 000419d4
    P8 : c0000409
    P9 : 00000007
    P10 : 

    Fichiers joints :
    \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER29F4.tmp.WERInternalMetadata.xml
    \\?\C:\Windows\Temp\WER359D.tmp.csv
    \\?\C:\Windows\Temp\WER35CD.tmp.txt
    \\?\C:\Users\PC \AppData\Local\Temp\WER35CD.tmp.appcompat.txt
    \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER367A.tmp.dmp
    \\?\C:\Users\PC \AppData\Local\Temp\WER36D8.tmp.WERDataCollectionFailure.txt
    C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_ToolConversion.e_1bf29b979975740a27557d876afe0a79d4cdd_3c5864c0_cab_ae1a36e5\memory.hdmp
    WERGenerationLog.txt

    Ces fichiers sont peut-être disponibles ici :
    C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_ToolConversion.e_1bf29b979975740a27557d876afe0a79d4cdd_3c5864c0_cab_ae1a36e5

    Symbole d’analyse : 
    Nouvelle recherche de la solution : 0
    ID de rapport : ce709d60-2306-437d-a994-823720440986
    Statut du rapport : 16396
    Récipient avec hachage : a1aa0158e42c73c8272e582080e9f6c8
    mardi 14 février 2017 11:12
  • Vous avez donc tout plein de fichiers à lire qui donne tout plein d'informations.

    Vous avez même des fichiers de dump (les .dmp et .hdmp) qui contient la mémoire du processus lors du crash.

    Avec VS et les fichiers de symboles de votre projet, vous pouvez voir précisément où et comment le programme à planter.


    Paul Bacelar, Ex - MVP VC++

    mardi 14 février 2017 14:15
    Modérateur
  • Sur la machine client on ne dispose pas de VS.
    L'application marche parfaitement sur 8.1 et versions antérieurs et pas pour le 10.
    mardi 14 février 2017 14:22
  • Pour résoudre le problème de compatibilité de mon application sur l'OS Windows 10 j'ai du cibler ce dernier à l'aide "l'app manifest"  

    Pour ce faire j'ai crée un fichier .xml contenant :

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
        <assemblyIdentity 
            type="win32" 
            name=SXS_ASSEMBLY_NAME
            version=SXS_ASSEMBLY_VERSION
            processorArchitecture=SXS_PROCESSOR_ARCHITECTURE
        />
        <description> my exe </description>
        <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
            <security>
                <requestedPrivileges>
                    <requestedExecutionLevel
                        level="asInvoker"
                        uiAccess="false"
                    />	
                </requestedPrivileges>
            </security>
        </trustInfo>
        <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"> 
            <application> 
                <!-- Windows 10 --> 
                <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
                <!-- Windows 8.1 -->
                <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
                <!-- Windows Vista -->
                <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/> 
                <!-- Windows 7 -->
                <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
                <!-- Windows 8 -->
                <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
            </application> 
        </compatibility>
    </assembly>

    En l'incluant dans un .rc et en changeant la propriété "Editeur de lien" => "Génération d'un manifeste" en
    NON (/MANIFEST:NO).

    Le problème "Application a cessé de fonctionner" n'apparaît plus.

    Pourriez-vous me clarifier les choses concernant l'intérêt de la génération du manifeste qui a permis de résoudre mon problème?
    Merci pour votre intervention @Paul Bacelar.

     

    mardi 14 février 2017 16:03
  • Sur la machine client on ne dispose pas de VS.
    L'application marche parfaitement sur 8.1 et versions antérieurs et pas pour le 10.

    Vous n'avez pas besoin d'avoir VS sur la machine du client.

    Il suffit de copier le ou les fichiers de dump là où un VS peut les ouvrir.

    Il y a assez d'information dans le dump pour récupérer les informations de débug du l'OS hôte client, même si VS est installé sur un OS qui n'a rien à voir. Il faut juste correctement configurer le serveur de symbole sous VS.

    P.S.: Il y a aussi pas mal de fichier texte en plus des fichiers de dump qui peuvent être lu sans VS, directement sur la machine client.

    Pour l'histoire du manifeste :

    Vos explications sont contradictoire, quelles sont les différences entre votre ressource et celles générées par le linker ?

    Vous n'avez peut-être juste que cacher le "vrai" problème ? => analyses des fichiers dump.

    Je ne suis même pas sûr que votre nouveau programme ait un "vrai" manifeste.

    Vous semblez vous mettre des œillères "c'est un problème de compatibilité". Mais, moi, je vois plus ce "problème" comme une chance de trouver un bug existant et voir Win10 comme un révélateur très pratique du problème.

    Les problèmes de compatibilité, c'est à posteriori, après une analyses, pas à priori.


    Paul Bacelar, Ex - MVP VC++


    mercredi 15 février 2017 13:11
    Modérateur