Exécution programme C sur Windows server 2008 - ntdll.dll ?

Version imprimable

J'ai codé un petit programme sous C:B depuis un poste XP PRO SP3, qui permet de vider des répertoires de logs en fonctions de la date des fichiers.
Ce programme fonctionne correctement sur un poste XP mais plante systématiquement si je l'exécute sur un windows server 2008 (<=> windows 7)
=> le programme se lance puis est interrompu, s'affiche une fenêtre avec ce message :

Citation:

Problem signature:
Problem Event Name: APPCRASH
Application Name: GestionFichier.exe
Application Version: 0.0.0.0
Application Timestamp: 4d9c93b6
Fault Module Name: ntdll.dll
Fault Module Version: 6.0.6002.18327
Fault Module Timestamp: 4cb73436
Exception Code: c0000005
Exception Offset: 00067445
OS Version: 6.0.6002.2.2.0.272.7
Locale ID: 1036
Additional Information 1: 3cd6
Additional Information 2: 1bf0753a414b1861dae36ba7052fbf5d
Additional Information 3: 45fa
Additional Information 4: 3e75e41d9a132c61775b2a51b198c572

Read our privacy statement:
http://go.microsoft.com/fwlink/?link...3&clcid=0x0409

Comme j'ai pu lire ailleurs, est-ce parce que j'ai utilisé des fonctions qui ne sont plus compatibles avec l'OS?

Je vous mets mes en-têtes ci-dessous
Code:

1 2 3 4 5 6 7 8 9 10 #include <stdio.h> #include <stdlib.h> #include <Windows.h> #include <string.h> #include <dirent.h> #include <time.h> #include <sys/types.h> #include <sys/stat.h> #include <locale.h> #include <unistd.h>
Fonctions API WIN32 utilisée:
Code:

1 2 GetFileAttributesEx GetLocalTime
Fonctions "exotiques" utilisées (POSIX ?) :
Code:

1 2 opendir difftime
En complément j'ai compilé le programme sur la machine cible avec succès (pas d'erreur ni warning) et j'observe le même résultat : au lancement, le programme est bloqué et je vois apparaître le même message cité plus haut :(

Toute aide sera la bienvenue, merci d'avance.

06/04/2011, 20h32
sevyc64

Quels sont les répertoires que tu essaye de vider ? N'est-ce pas un problème de droit sur ces répertoires ?

PS : Pour info, Windows Server 2008 n'est pas "l'équivalent" de W7, mais de Vista. "L’équivalent" de W7 c'est Windows Server 2008 R2
06/04/2011, 23h00
rin01

Les répertoires en question sans dans c:\backup\logs et c:\backup\db
En regardant les droits, je les vois en "read only" et je ne peux pas les changer.
Mais en éditant les propriétés avancées je vois que le compte SYSYEM a "full control" sur ces répertoires.
Le fait de lancer l'executable en tant qu'administrateur donne le même résultat d'ailleurs...
Je commence à desespérer

PS: Je m'embrouille avec la version de l'OS, dans les propriétés je vois: windows server standard (copyright 2007 ) sp2
07/04/2011, 16h22
sevyc64

Question OS :

Citation:

OS Version: 6.0.6002.2.2.0.272.7

6.0 indique Vista ou Windows Server 2008
le 2 du 6002 indique le Service Pack 2

Si tu avais W7/WS2008 R2 tu aurais 6.1.7600 ou 6.1.7601 avec le SP1

Concernant les droits, normalement le compte SYSTEM à le contrôle total sur l'ensemble des dossiers et fichiers du disque. Ce qui compte ces les droit de l'utilisateur ou du groupe correspondant à la session dans laquelle tu exécute ton logiciel.

Citation:

Le fait de lancer l'executable en tant qu'administrateur donne le même résultat d'ailleurs...

A partir de Vista, un compte administrateur a, par défaut, les mêmes droits qu'un compte utilisateur. Pour avoir les droits administrateur, être avec un compte administrateur ne suffit pas. Il faut bien faire en plus, un click droit sur l’exécutable et choisir "Executer en tant qu'administrateur"

Tu dis avoir recompiler sur la cible, tu as certainement donc dû installer l'environnement de développement. Si tu fais une exécution pas à pas dans cet environnement, tu peux sur qu'elle instruction exactement il plante.
09/04/2011, 00h20
rin01

Merci pour ces réponses dignes d'enseignement!
Effectivement j'ai eu l'idée de debugger sur la machine cible et arrivé à un moment j'ai un SIGSERV.
En consultant mes vieux bouquins, j'ai vu que c'était lié à un problème de mémoire.
J'ai pas mal d'allocations dynamiques de pointeurs (char *) :lol: et je suppose que ça pourrait venir de là.
Là où je suis un peu désorienté c'est que le programme en question tourne nickel sur mon poste XP PRO...
Pourquoi il y aurait un tel écart?
09/04/2011, 08h24
sevyc64

Peut-être un problème d'architecture 32 ou 64bits

1 pièce(s) jointe(s)

Je pensais que même avec 2 uc, les instructions étaient en 32 bits...?
(voir screenshot)

Bref, j'ai débuggué et j'ai trouvé à quel moment le SIGSEV était envoyé. C'est dans la fonction suivante:
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 void writeLogs(char* pMsg) { SYSTEMTIME lt; char* pAppend; FILE* pfichier = NULL; pAppend = (char*)malloc(sizeof(char)+ strlen(pMsg)+1+25); if (pAppend != NULL) { //Get date 'YYYY-MM-DD HH:MM:SS:MS --' GetLocalTime(&lt); //create date prefix sprintf(pAppend,"%04d-%02d-%02d %02d:%02d:%02d:%02d -- ",lt.wYear,lt.wMonth,lt.wDay,lt.wHour,lt.wMinute,lt.wSecond,lt.wMilliseconds); //concatene prefix & msg strcat(pAppend,pMsg); //write string to logs file pfichier = fopen("Purge.log","a"); if (pfichier != NULL) { fprintf(pfichier,"%s",pAppend); fclose(pfichier); } free(pAppend); } }
Puis dans le journal j'ai ceci

Citation:

Building to ensure sources are up-to-date
Build succeeded
Selecting target:
Debug
Adding source dir: C:\Users\Administrator\Documents\GestionFichier\
Adding source dir: C:\Users\Administrator\Documents\GestionFichier\
Adding file: bin\Debug\GestionFichier.exe
Starting debugger:
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Debugger name and version: GNU gdb 6.7.50.20071127
Child process PID: 3272
At C:/Users/Administrator/Documents/GestionFichier/myfunction.c:209
At C:/Users/Administrator/Documents/GestionFichier/myfunction.c:135
At C:/Users/Administrator/Documents/GestionFichier/myfunction.c:137
At C:/Users/Administrator/Documents/GestionFichier/myfunction.c:139
At C:/Users/Administrator/Documents/GestionFichier/myfunction.c:143
At C:/Users/Administrator/Documents/GestionFichier/myfunction.c:144
At C:/Users/Administrator/Documents/GestionFichier/myfunction.c:210
At C:/Users/Administrator/Documents/GestionFichier/myfunction.c:229
At C:/Users/Administrator/Documents/GestionFichier/myfunction.c:230
At C:/Users/Administrator/Documents/GestionFichier/myfunction.c:232
At C:/Users/Administrator/Documents/GestionFichier/myfunction.c:233
At C:/Users/Administrator/Documents/GestionFichier/myfunction.c:234
At C:/Users/Administrator/Documents/GestionFichier/myfunction.c:236
At C:/Users/Administrator/Documents/GestionFichier/myfunction.c:237
At C:/Users/Administrator/Documents/GestionFichier/myfunction.c:238
At C:/Users/Administrator/Documents/GestionFichier/myfunction.c:241
At C:/Users/Administrator/Documents/GestionFichier/myfunction.c:243
At C:/Users/Administrator/Documents/GestionFichier/myfunction.c:259
At C:/Users/Administrator/Documents/GestionFichier/myfunction.c:260
At C:/Users/Administrator/Documents/GestionFichier/myfunction.c:261
At C:/Users/Administrator/Documents/GestionFichier/myfunction.c:173
At C:/Users/Administrator/Documents/GestionFichier/myfunction.c:176
At C:/Users/Administrator/Documents/GestionFichier/myfunction.c:179
At C:/Users/Administrator/Documents/GestionFichier/myfunction.c:182
At C:/Users/Administrator/Documents/GestionFichier/myfunction.c:185
At C:/Users/Administrator/Documents/GestionFichier/myfunction.c:186
At C:/Users/Administrator/Documents/GestionFichier/myfunction.c:188
At C:/Users/Administrator/Documents/GestionFichier/myfunction.c:189
At C:/Users/Administrator/Documents/GestionFichier/myfunction.c:191
Program received signal SIGTRAP, Trace/breakpoint trap.In ntdll!DbgUiConvertStateChangeStructure () (C:\Windows\system32\ntdll.dll)
In ntdll!RtlpNtMakeTemporaryKey () (C:\Windows\system32\ntdll.dll)
In ntdll!RtlInitAnsiStringEx () (C:\Windows\system32\ntdll.dll)
In ntdll!EtwpNotificationThread () (C:\Windows\system32\ntdll.dll)
In ntdll!DbgUiDebugActiveProcess () (C:\Windows\system32\ntdll.dll)
In ntdll!RtlAddVectoredExceptionHandler () (C:\Windows\system32\ntdll.dll)
In ntdll!RtlGetAce () (C:\Windows\system32\ntdll.dll)
In ntdll!RtlAddVectoredExceptionHandler () (C:\Windows\system32\ntdll.dll)
In ntdll!EtwpNotificationThread () (C:\Windows\system32\ntdll.dll)
In ntdll!memcpy () (C:\Windows\system32\ntdll.dll)
In ntdll!EtwpNotificationThread () (C:\Windows\system32\ntdll.dll)
In ntdll!DbgUiStopDebugging () (C:\Windows\system32\ntdll.dll)
In vsnprintf () (C:\Windows\system32\ntdll.dll)
In ntdll!KiUserCallbackDispatcher () (C:\Windows\system32\ntdll.dll)
In wcstombs () (C:\Windows\system32\ntdll.dll)
In ntdll!RtlUnicodeToMultiByteSize () (C:\Windows\system32\ntdll.dll)
In ntdll!LdrGetProcedureAddress () (C:\Windows\system32\ntdll.dll)
In ntdll!RtlUnicodeToMultiByteSize () (C:\Windows\system32\ntdll.dll)
In ntdll!RtlDosApplyFileIsolationRedirection_Ustr () (C:\Windows\system32\ntdll.dll)
(...)

Une idée?

10/04/2011, 14h37
rin01
Dans mon programme principal, j'ai enlevé tous les appels à la fonction writeLogset ça a fonctionné, ce qui prouve que c'est cette fonction qui est incriminée ;)

En modifiant

Code:

pAppend = (char*)malloc(sizeof(char)+ strlen(pMsg)+1+25);

par

Code:

pAppend = (char*)malloc(1024 + lg+1+25);

où
Code:

1 2 size_t lg=0; lg = sizeof(pMsg);
J'ai choisi la valeur de 1024 arbitrairement mais j'imagine que si pMsg contient une chaîne plus longue alors je vais reproduire de nouveau l'erreur.

Comment fixer cette valeur pour éviter les débordements?
10/04/2011, 15h48
sevyc64

Je ne pense pas que ce soit ça qui résolve ton problème mais ton allocation mémoire ne devrait pas plutot être

Code:

sizeof(char)*( strlen(pMsg)+1+25)

?
10/04/2011, 16h29
rin01

Si j'alloue de cette manière

Code:

pAppend = (char*)malloc(sizeof(char)*(strlen(pMsg)+1+25));

où

Code:

pAppend = (char*)malloc(sizeof(char)*(sizeof(pMsg)+1+25));

Je reproduis l'erreur!
10/04/2011, 16h41
sevyc64

Si je compte bien ceci

Citation:

"%04d-%02d-%02d %02d:%02d:%02d:%02d -- "

représente 26 caractères et non pas 25 comme tu semble le comptabiliser dans ton allocation, non?

C'est exact, en gros je voulais prefixer mon msg par un timestamp de la forme :

Citation:

YYYY-MM-DD HH:MM:SS:MS --

qui fait effectivement 26 caractères et non 25 :oops:

Du coup, j'ai modifié ma fonction comme ceci pour être tranquille

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
void writeLogs(char* pMsg)
{
SYSTEMTIME lt;
char* pAppend;
FILE* pfichier = NULL;
size_t lg=0;
 
lg = sizeof(pMsg);
if (lg >0)
    {
    pAppend = (char*)malloc(lg * (1+26));
 
    if (pAppend != NULL)
        {
        //Get date 'YYYY-MM-DD HH:MM:SS:MS --'
        GetLocalTime(&lt);
 
        //create date prefix
        sprintf(pAppend,"%04d-%02d-%02d %02d:%02d:%02d:%02d -- ",lt.wYear,lt.wMonth,lt.wDay,lt.wHour,lt.wMinute,lt.wSecond,lt.wMilliseconds);
 
        //concatene prefix & msg
        strcat(pAppend,pMsg);
 
        //write string to logs file
        pfichier = fopen("Purge.log","a");
        if (pfichier != NULL)
            {
            fprintf(pfichier,"%s",pAppend);
            if (pAppend != NULL) free(pAppend);
            fclose(pfichier);
            }
 
        }
    }
}

Est-ce que ça te paraît carré où y-at-il des choses à améliorer?

Dans tous les cas merci d'avoir pris le temps de m'aider :-)

10/04/2011, 17h25
sevyc64

Pour moi, non c'est pas bon.

Code:

pAppend = (char*)malloc(lg * (1+26));

Tu vas alloué 27 fois la taille de ton message, alors que tu veux allouer la taille de ton message +27.
De plus, tu alloue des octets, c'est partir du principe que 1 caractère = 1 octet. Je ne connais pas assez le C pour savoir si c'est toujours le cas. Notamment comment est géré le cas de caractères unicode sur 2 à 4 octets ?

Code:

if (pfichier != NULL) { fprintf(pfichier,"%s",pAppend); if (pAppend != NULL) free(pAppend); fclose(pfichier); }

Tu vas désallouer ta mémoire que si tu as réussi à avoir un pointeur sur ton fichier. Hors, même si tu n'obtient pas le pointeur sur ton fichier, tu as quand même déjà allouer la mémoire, il faut la désallouer quand même.

Pour l'instant je ne vois que ça, mais comme je ne suis pas expert en C (ça fait des années que je n'en ai pas fait) je peut passer à coté de d'autres choses.

Ceci est faux
Code:

1 2 3 4 lg = sizeof(pMsg); if (lg >0) { pAppend = (char*)malloc(lg * (1+26));
lg prend pour valeur le nombre de bytes de pMsg. pMsg est un pointeur donc lg prend pour valeur la taille d'un pointeur, pas du tout la taille de la chaine pointée qui peut être obtenue par strlen() :

Code:

pAppend = malloc(strlen(pMsg)+26+1);

Ce qui devrait donner : (codes non testés)
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 void writeLogs(char* pMsg) { SYSTEMTIME lt; FILE* pfichier ; char * pAppend = malloc(strlen(pMsg)+26+1); if (pAppend != NULL) { sprintf(pAppend,"%04d-%02d-%02d %02d:%02d:%02d:%02d -- %s", lt.wYear,lt.wMonth,lt.wDay,lt.wHour,lt.wMinute,lt.wSecond,lt.wMilliseconds,pMsg); pfichier = fopen("Purge.log","a"); if (pfichier != NULL) { fprintf(pfichier,"%s\n",pAppend); fclose(pfichier); } free(pAppend); } }
Mais pourquoi stocker cette chaine ?
Code:

1 2 3 4 5 6 7 8 9 10 11 void writeLogs(char* pMsg) { SYSTEMTIME lt; FILE* pfichier = fopen("Purge.log","a"); if (pfichier != NULL) { fprintf(pfichier,"%04d-%02d-%02d %02d:%02d:%02d:%02d -- %s\n", lt.wYear,lt.wMonth,lt.wDay,lt.wHour,lt.wMinute,lt.wSecond,lt.wMilliseconds,pMsg); fclose(pfichier); } }
Remarques accessoires :
- le résultat d'un sizeof sur un objet est toujours >0 (type size_t qui est un entier non signé)
- sizeof (char) vaut toujours 1
- sizeof renvoie la taille en nombre de bytes (pas en nombre d'octets) même si le plus souvent un byte correspond à un octet. Donc un char occupe toujours un byte.

11/04/2011, 20h40
rin01

Ok, merci pour ces réponses éclairées.
J'ai "stocké" car je veux concaténer la date et le message

Citation:

"YYYY-MM-DD HH:MM:SS:MS -- " + "mon message"

La date est obtenue avec GetLocalTime() et le message dans le pointeur pMsg
Dans ma tête c'est ce qui me paraissait le plus simple à faire.
Dans tous les cas merci beaucoup, ça m'enlève une grosse épine du pied :ccool: