problème de crash soft MFC80 - CRT80

Version imprimable

Bonjour,

J'ai un crash soft pas très fréquent mais tout de même régulier.
Le soft en question est installé sur un poste en XP où le .Net framework 3.5 est déjà installé avec la version 8.0.50727.3053 de msvcr80.dll et msvcp80.dll.
Le soft est développé sous VS2005, installé avec le vc_redist_x86 de vs2005 soit avec la version 8.0.52727.762 msvcr80.dll, msvcp80.dll et mfc80u.dll

ci-dessous un extrait du log de Dr watson:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
 
Application exception occurred:
        App: C:\Program Files\ALW\HPC\Safmain.exe (pid=3544)
        When: 11/17/2015 @ 07:35:38.640
        Exception number: c0000005 (access violation)
...
...
(0000000078130000 - 00000000781cb000: C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.3053_x-ww_b80fa8ca\MSVCR80.dll
(00000000782e0000 - 00000000783ef000: C:\WINDOWS\WinSxS\x86_Microsoft.VC80.MFC_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_3bf8fa05\MFC80U.DLL
(000000007c420000 - 000000007c4a7000: C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.3053_x-ww_b80fa8ca\MSVCP80.dll
(000000007c800000 - 000000007c8f6000: C:\WINDOWS\system32\kernel32.dll
(000000007c900000 - 000000007c9b2000: C:\WINDOWS\system32\ntdll.dll
(000000007c9c0000 - 000000007d1d7000: C:\WINDOWS\system32\SHELL32.dll
(000000007e410000 - 000000007e4a1000: C:\WINDOWS\system32\USER32.dll
(000000007e720000 - 000000007e7d0000: C:\WINDOWS\system32\SXS.DLL
 
*----> State Dump for Thread Id 0xde0 <----*
 
eax=1b841000 ebx=1b840fc8 ecx=00000007 edx=00000073 esi=003c2756 edi=7fffffe2
eip=7813f880 esp=0012e468 ebp=0012e4f4 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000206
 
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.3053_x-ww_b80fa8ca\MSVCR80.dll - 
function: MSVCR80!flsbuf
        7813f871 45               inc     ebp
        7813f872 e48b             in      al,8b
        7813f874 45               inc     ebp
        7813f875 e4c7             in      al,c7
        7813f877 45               inc     ebp
        7813f878 cc               int     3
        7813f879 0100             add     [eax],eax
        7813f87b 0000             add     [eax],al
        7813f87d eb09             jmp     MSVCR80!flsbuf+0x8fd (7813f888)
        7813f87f 4f               dec     edi
FAULT ->7813f880 66833800         cmp     word ptr [eax],0x0    ds:0023:1b841000=????
        7813f884 7406             jz      MSVCR80!flsbuf+0x901 (7813f88c)
        7813f886 40               inc     eax
        7813f887 40               inc     eax
        7813f888 85ff             test    edi,edi
        7813f88a 75f3             jnz     MSVCR80!flsbuf+0x8f4 (7813f87f)
        7813f88c 2b45e4           sub     eax,[ebp-0x1c]
        7813f88f d1f8             sar     eax,1
        7813f891 8945e0           mov     [ebp-0x20],eax
        7813f894 837db800         cmp     dword ptr [ebp-0x48],0x0
        7813f898 0f85ff000000     jne     MSVCR80!flsbuf+0xa12 (7813f99d)
 
*----> Stack Back Trace <----*
WARNING: Stack unwind information not available. Following frames may be wrong.
ChildEBP RetAddr  Args to Child              
0012e4f4 00000000 00000000 00000000 00000000 MSVCR80!flsbuf+0x8f5
 
*----> Raw Stack Dump <----*
000000000012e468  14 ea 12 00 00 00 00 00 - 95 4e 38 00 00 00 00 00  .........N8.....
000000000012e478  01 00 00 00 00 00 00 00 - 00 00 00 00 30 00 00 00  ............0...
000000000012e488  00 00 00 00 07 00 00 00 - 58 a9 41 0f e8 2c 16 01  ........X.A..,..
000000000012e498  90 1e 16 01 01 00 00 00 - 27 00 00 00 00 00 00 00  ........'.......
000000000012e4a8  56 27 3c 00 00 00 00 00 - 00 00 00 00 00 00 00 00  V'<.............
000000000012e4b8  04 e9 12 00 00 00 00 00 - 01 00 00 00 00 00 00 00  ................
000000000012e4c8  74 00 00 00 7c e9 12 00 - 73 00 00 00 0f 00 00 00  t...|...s.......
000000000012e4d8  c8 0f 84 1b ff ff ff ff - 00 00 00 00 00 00 00 00  ................
000000000012e4e8  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00  ................
000000000012e4f8  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00  ................
000000000012e508  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00  ................
000000000012e518  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00  ................
000000000012e528  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00  ................
000000000012e538  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00  ................
000000000012e548  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00  ................
000000000012e558  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00  ................
000000000012e568  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00  ................
000000000012e578  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00  ................
000000000012e588  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00  ................
000000000012e598  00 00 00 00 00 00 00 00 - d4 e5 12 00 00 00 16 01  ................

Pensez-vous que le fait que MFC80u.dll et les dll CRT ne soient pas à la même révision soient l'origine de mon problème ?
Comment faire pour forcer l'utilisation des dlls CRT en rev 762 ?

Merci

03/12/2015, 12h02
Médinoc

C'est probablement lié au problème en effet.
Personnellement, j'utilise toujours la dernière version des redistribuables sur ma machine de dev, donc j'ai au pire des erreurs SxS sur la machine de destination.
03/12/2015, 14h08
dus

Je suis coincé avec Visual Studio 2005 sur ma machine de dev. Et je ne crois pas qu'il y ait plus récent que la rev 762 en redistribuable pour VS2005.
N'y a t'il pas moyen de forcer le chargement des dlls en rev 762 par le manifeste.

Merci de votre intérêt.
03/12/2015, 15h39
Médinoc

Quand je regarde dans mon dossier WinSxS, j'ai des révisions allant jusqu'à 6229 (il me semble qu'il y a d'abord le SP1, puis des correctifs via Windows Update).

La dernière version que j'ai téléchargée sur le site de MS ("Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package MFC Security Update") contenait la révision 6195, donc la 6229 doit venir d'un Windows Update.
03/12/2015, 18h46
dus

En y regardant de plus près, j'ai les MFC 8.0 et les CRT 8.0 en rev 42, 762, 1833, 4027, 4053 et 6195 dans mon winsxs.
Par contre je tourne sous VS 2005 en rev 42 car le SP1 n'a pas été installé et tous mes collègues sont dans le même cas.
Si je me souviens bien, j'avais eu des soucis d'exécution en mode debug sur un précédent PC après avoir installé le SP1.

Sur les cibles, les crt présentes sont les rev 42, 762 et 3053, et les mfc en 42 et 762
Comment le soft décide de charger la mfc rev 762 et les CRT en 3053 ?

J'ai réussi à générer un manifest précisant les versions des dlls que je veux charger:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <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.CRT" version="8.0.50727.762" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="x86" publicKeyToken="6595b64144ccf1df" language="*"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
</assembly>

Je génère ensuite volontairement une access violation pour que Dr Watson fasse son job.
Les dlls chargées sont toujours les plus récentes du système sur lequel je fais le test (6195 sur mon poste de dev sous W7, 3053 sur une cible sous XP).
J'avoue que ça commence à me #!%***$££"# !!!

04/12/2015, 19h42
Médinoc

Il me semble que WinSxS contient des redirections pour les DLLs plus récentes qui sont supposées compatibles.
07/12/2015, 08h48
dus

Du coup j'ai téléchargé le redist SP1 qui installe les dlls en rev 6195.
Je vais déployer ça sur une machine sur laquelle le problème a été remonté, et on va voir si il y a de l'amélioration.
Sachant que le problème pouvait arriver une fois dans la journée, puis plus du tout pendant une semaine, on n'aura pas de certitudes avant un moment.

Merci à Medinoc de son aide.

L'installation des dlls en rev 6195 n'a rien apporté:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
 
Application exception occurred:
        App: C:\Program Files\ALW\HPC\Safmain.exe (pid=148)
        When: 3/2/2016 @ 09:05:49.140
        Exception number: c0000005 (access violation)
...
(0000000078130000 - 00000000781cb000: C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.6195_x-ww_44262b86\MSVCR80.dll
(00000000782e0000 - 00000000783ef000: C:\WINDOWS\WinSxS\x86_Microsoft.VC80.MFC_1fc8b3b9a1e18e3b_8.0.50727.6195_x-ww_150c9e8b\MFC80U.DLL
(000000007c420000 - 000000007c4a7000: C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.6195_x-ww_44262b86\MSVCP80.dll
...
*----> State Dump for Thread Id 0x11c <----*
 
eax=0f762000 ebx=0f761fc8 ecx=00000007 edx=00000073 esi=003c2756 edi=7fffffe2
eip=7813f880 esp=0012e4e8 ebp=0012e574 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000206
 
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.6195_x-ww_44262b86\MSVCR80.dll - 
function: MSVCR80!flsbuf
        7813f871 45               inc     ebp
        7813f872 e48b             in      al,8b
        7813f874 45               inc     ebp
        7813f875 e4c7             in      al,c7
        7813f877 45               inc     ebp
        7813f878 cc               int     3
        7813f879 0100             add     [eax],eax
        7813f87b 0000             add     [eax],al
        7813f87d eb09             jmp     MSVCR80!flsbuf+0x8fd (7813f888)
        7813f87f 4f               dec     edi
FAULT ->7813f880 66833800         cmp     word ptr [eax],0x0    ds:0023:0f762000=????
        7813f884 7406             jz      MSVCR80!flsbuf+0x901 (7813f88c)
        7813f886 40               inc     eax
        7813f887 40               inc     eax
        7813f888 85ff             test    edi,edi
        7813f88a 75f3             jnz     MSVCR80!flsbuf+0x8f4 (7813f87f)
        7813f88c 2b45e4           sub     eax,[ebp-0x1c]
        7813f88f d1f8             sar     eax,1
        7813f891 8945e0           mov     [ebp-0x20],eax
        7813f894 837db800         cmp     dword ptr [ebp-0x48],0x0
        7813f898 0f85ff000000     jne     MSVCR80!flsbuf+0xa12 (7813f99d)
 
*----> Stack Back Trace <----*
WARNING: Stack unwind information not available. Following frames may be wrong.
ChildEBP RetAddr  Args to Child              
0012e574 00000000 00000000 00000000 00000000 MSVCR80!flsbuf+0x8f5
 
*----> Raw Stack Dump <----*
000000000012e4e8  94 ea 12 00 00 00 00 00 - 95 4e 38 00 00 00 00 00  .........N8.....
000000000012e4f8  01 00 00 00 00 00 00 00 - 00 00 00 00 30 00 00 00  ............0...
000000000012e508  00 00 00 00 07 00 00 00 - d8 a7 3e 0f e8 2c 16 01  ..........>..,..
000000000012e518  90 1e 16 01 01 00 00 00 - 27 00 00 00 00 00 00 00  ........'.......
000000000012e528  56 27 3c 00 00 00 00 00 - 00 00 00 00 00 00 00 00  V'<.............
000000000012e538  84 e9 12 00 00 00 00 00 - 01 00 00 00 00 00 00 00  ................
000000000012e548  74 00 00 00 fc e9 12 00 - 73 00 00 00 0f 00 00 00  t.......s.......
000000000012e558  c8 1f 76 0f ff ff ff ff - 00 00 00 00 00 00 00 00  ..v.............
000000000012e568  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00  ................
000000000012e578  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00  ................
000000000012e588  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00  ................
000000000012e598  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00  ................
000000000012e5a8  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00  ................
000000000012e5b8  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00  ................
000000000012e5c8  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00  ................
000000000012e5d8  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00  ................
000000000012e5e8  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00  ................
000000000012e5f8  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00  ................
000000000012e608  00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00  ................
000000000012e618  00 00 00 00 00 00 00 00 - 54 e6 12 00 00 00 16 01  ........T.......

Si quelqu'un a une idée ou une astuce qui puisse m'aider à identifier une piste...

04/03/2016, 19h40
bacelar

Sauf erreur de ma part, on n'est plus dans le cas d'un mélange de C-Runtime ou de MFC.

On n'est donc avec une bonne grosse exception mémoire "classique", non ?

Si oui, on utilise les outils habituels.

Vous activez Dr Watson pour générer un full dumpfile. (voir utiliser des outils comme AutoDumpPlus pour avoir plus de confort)

Après le crash, utilisez ce dumpfile avec VS ou WinDBG pour voir précisément le problème.
Il faudra faire attention à disposer des fichiers .pdb correspondant aux versions de production et à configurer votre machine de dev/d'autopsie pour qu'elle récupère automatiquement les fichiers de symboles vie le serveur de symbole de M$.
17/03/2016, 17h41
dus

Je viens de recevoir un full dump d'une machine qui a le problème.
Il a quand même fallu plus d'une semaine de fonctionnement pour obtenir le crash.
Je pense avoir isolé le problème. Reste à le corriger...

Merci à Bacelar pour ses conseils avisés.