Bonjour, 

j'ai retrouver le code d'un petit programm que j'utilisais sur un vieux windows 32bit et je n'arrive pas a le faire fonctionner sur windows 64bit. j'ai une erreur de mfc42.dll. 

j'ai ouvert le code avec Blend  pour Visual Studio 2019. j'ai 48 warning qui sont tous pareille. 

Code d'erreur C6284 sur les ligne suivante pour n'en mettre que 2 

 strTemp.Format("cConfig.strSource= %-20s\n", cConfig.strSource);

strTemp.Format("\nFile SENDER= %-20s RECEIVER= %-20s", fileSender, fileReceiver);

Je ne suis pas un grand programmeur c'étais un ancien ami qui l'avais fait. J'essai juste de trouver comment le faire fonctionner maintenant. 

Le programme en gros prend des fichier dans un repertoire mentionner. regarde l'envoyeur et le receveur et baser la dessus déplace le fichier au chemin donner dans le .ini

Si quelqu'un pourrais me corriger une ligne me montrer comment je peux les arranger j'apprécirais beaucoup. Fait 2 jours j'essai de trouver et j'y arrive pas. 

Merci beaucoup pour votre aide. 

Marc 

-
Edité par rouloude 16 septembre 2020 à 15:30:44

non sa ne fonctionne pas dutout quand j'exécute le .exe j'ai une erreur  le programme a cesser de fonctionner  et si je vais dans les détails 

 Problem Event Name:APPCRASH

  Application Name:FileMover.exe

  Application Version:0.0.0.0

  Application Timestamp:3e4971b1

  Fault Module Name:MFC42.DLL

  Fault Module Version:6.6.8064.0

  Fault Module Timestamp:4d79b3c0

  Exception Code:c0000005

  Exception Offset:0001b2cd

  OS Version:6.1.7600.2.0.0.274.10

  Locale ID:4105

  Additional Information 1:0a9e

  Additional Information 2:0a9e372d3b4ad19135b953a78882e789

  Additional Information 3:0a9e

  Additional Information 4:0a9e372d3b4ad19135b953a78882e789

mais la dll est bien présente dans c:\windows\system32

UPDATE:  Ok j'ai recompiller sur mon pc et fait des test le programme fonctionne bien. Quand je le transfer sur mon serveur 2008 R2 entreprise  j,ai une erreur MFC140d.dll manquant.  j'ai tente d'installer le Redistribution++ mais ce n'est pas fait pour ma version de windows. J'ai télécharger le DLL et je l'ai mis dans system32 mais quand j'arrive pour l'enregistrer sa plante .. Je n,arrive plus a trouver quoi faire 

-
Edité par Marc_Moi 16 septembre 2020 à 17:57:30

"Blend pour VS2019", c'est un compilateur ce machin, depuis quand ???

Moralité, on ne sait pas si tu utilises une exécutable que tu as toi-même compilé ou si c'est un "ancien" exécutable que tu utilises.

Cela change beaucoup de chose dans la manière d'analyser le problème.

"C6284", c'est pas une erreur mais un warning :

https://docs.microsoft.com/fr-fr/cpp/code-quality/c6284?view=vs-2019

En fonction de comment est configuré ton espace de travail, soit ça bloque la génération et on travaille sur un vieux machin et on sait même pas si les sources sont alignées avec le vieux machin. Soit ça laisse passer (configuration pour Mickey, mais par défaut) et on génère un exécutable mais tu nous donnes absolument aucun détail aussi bien sur la configuration de toute la chaîne de compilation (en particulier, elle sort d'où la lib qui fait le lien avec la Dll "mfc42.dll" ?, concrètement, il y en a par dizaine) que sur l'environnement d'exécution lors du test (des mfc42.dll, il y en a aussi des dizaines).

Clairement, ces warning ne sont à prendre à la légère car elles peuvent facilement générer des GPF (générale protection fault) et la référence (1er lien du post) donne des exemples pour sécuriser ce code.

Pour les corriger, c'est fonction du type concret des bidules passés en paramètre de la fonction Format. Il faut donc que vous analysiez un peu plus le code pour correctement le corriger.

Le 'c0000005' mentionné dans le rapport d'erreur, c'est pile poil une GPF, comme par hasard. Je ne dis pas que c'est forcément l'un des appels à Format qui déconne mais c'est cohérent avec le reste.

Le crash à lieu dans la dll "MFC42.DLL", c'est dans le rapport de crash, et si c'est un objet, dont on appelle la fonction "Format", est créé par les MFC, l'appel de la fonction entraîne un passage dans la Dll, et si on lui envoie de la merde en paramètre (ce qu'indique le warning), bin c'est bien la Dll qui va cracher, même si c'est l'appelant qui envoie de la merde.

Et même si ce qui est envoyé à la fonction est correcte, rien ne garantit que cela soit correctement encodé pour la prise en charge par le code de la Dll, car rien ne nous garantit que la Dll chargée dans "FileMover.exe" est celle correspondante au .lib utilisé lors de l'édition de lien ou aux .h lors de la compilation (et les .def, etc...). Et, en plus, on a aucune garantie que c'est celle dans "c:\windows\system32" qui sera utilisée (et même tant mieux car "c:\windows\system32" c'est vraiment le dépotoir du nimpornawak, utiliser ProcessMonitor ( https://docs.microsoft.com/en-us/sysinternals/downloads/procmon ) pour être sûr de la Dll utilisée).

Alors, corrigez correctement les warning, et déployez correctement votre solution logicielle (en ne collant pas VOTRE "MFC42.DLL" dans le dépotoir, par exemple).

EDIT à l'UPDATE du poste du dessus : Vous êtes en train de faire nimpornawak, respectez mon 2ème point "déployez correctement votre solution logicielle".

Primo, le "d" dans le nom de la Dll, c'est pour la version "debug", qui n'a pas à sortir des machines de développement et donc encore moins à être sur un serveur et encore encore moins dans son dépotoir (BORDEL).

Le fait que cela "fonctionne" avec la version Debug est peut-être un effet de bord du blindage supplémentaire qu'on les versions debug, pour aider au debugging, du fait que vous lanciez l'exécutable sans débogueur attaché ni d'environnement configuré pour s'en servir correctement (généralement fait lors de l'installation des outils de développement et non lors de l'installation d'une "Redistribution" (qui n'a pas à installer les versions debug qui n'ont rien à foutre ailleurs que sur les machines de Dev (et de Tests Unitaires))) réduisant ainsi les mécanisme de détection d'erreur de celle-ci, mais aussi très probablement en esquivant la version Release toute moisi qui traîne dans votre dépotoir de la machine de développement.

Donc, on reprend, vous dégagez (en la renommant au cas où), la Dll dans votre dépotoir. Vous compilez en DEBUG votre programme et vous faite quelques tests avec, sur votre machine de développement. Ces tests doivent être fait dans le cadre du débogueur de VS. Puis vous compilez en RELEASE votre exécutable, et vous faites quelques tests, toujours dans débogueur de VS (même s'il râle un peu), si votre environnement n'est pas à la masse il trouvera automatiquement la bonne version de la Dll en RELEASE (regardez où il va la chercher en RELEASE pour savoir quelle redistribution il faut prendre (c'est fonction de la configuration de votre projet dans VS, donc si vous êtes pommé, ProcessMonitor ou le ProcessExplorer sont vos amis)).

Après, vous devriez être dans de bonnes conditions pour construire le MSI qui va bien pour votre exécutable ET ses Dll.

-
Edité par bacelar 16 septembre 2020 à 18:51:57

Salut, 

merci beaucoup d'avoir pris le temps de m'ecrire tous cela... 

désoler d'avoir ecris plusieurs choses qui mélange le tout. 

l'exécutable j'ai le code source en ma possession c'est du vieux C++ fait en 2006 je crois par un ami a qui je ne parle plus.  Maintenant j'ouvre le projet avec Visual studio 2019 et j'ai les 48 warnings. 

 strTemp.Format("cConfig.strSource= %-20s\n", cConfig.strSource);

le warning ci-dessus est 

SeverityCodeDescriptionProjectFileLineSuppression State

WarningC6284Object passed as _Param_(2) when a string is required in call to 'ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > >::Format' Actual type: 'class ATL::CStringT<char,class StrTraitMFC_DLL<char,class ATL::ChTraitsCRT<char> > >'.EDIFileMoverE:\Dev\EDIFileMover\EDIFileMover\EDIFileMover.cpp105

Pour le warning C6284, c'est toujours le même problème : "cConfig.strSource" n'est pas du bon type :

https://stackoverflow.com/questions/38850913/varargs-and-conversion-operators-in-mfc-cstring

Pour résoudre correctement le problème, c'est fonction du type de "cConfig.strSource".

Dans l'exemple de la Q&A dont j'ai donné le lien, c'est un CString qui était passée en paramètre, dans ce cas, c'est un appel à la fonction "c_str()" de CString qu'il faut utiliser.

>Je crois que le problème viens de la structure de la commande.

Où vous voyez des commandes ????

C'est les paramètres de l'appel de la fonction qui ne sont pas bons.

Cela "fonctionne" sur votre machine Win7, non pas parce que c'est un Win7, mais parce que vous avez installé les outils de développements pour MFC (via le workload MFC de Visual Studio vraisemblablement), donc installé une version compatible des MFC avec les programmes censés être générés par votre outils de développement.

Pour le déploiement d'une application MFC sur une machine, c'est pas une bête copie à l'arrache de 3 fichiers qui se battent en duel qu'il faut faire.

C'est faire un projet de déploiement pour générer un MSI contenant un MSM d'installation des MFC, compatible aussi bien avec la plateforme cible/hôte qu'avec l'exécutable qui vient d'être généré.

https://docs.microsoft.com/en-us/cpp/windows/walkthrough-deploying-a-visual-cpp-application-by-using-a-setup-project?view=vs-2019

Merci beaucoup. 

Je vais regarder a tous cela.  Désoler j'aurai pas du utiliser Commande pour mentionner la fonction. C'est très important ce petit programme pour ma compagnie alors je vais faire tout mon possible pour qu'il fonctionne.

Merci encore et je vous tien au courant de mon développement. 

bonne journée a vous.