Plantage d'une application CWinApp traitement particuliers

Version imprimable

06/12/2006, 09h59
Aradesh

Plantage d'une application CWinApp traitement particuliers
Bonjour,

je travaille sur un projet utilisant les MFC. J'ai une classe qui dérive de CWinApp. Il arrive que le programme plante où que je veuille faire planter le programme volontairement par exemple avec un code comme celui ci dessous :
Code:

1 2 3 int* i = 0;*i = 8;
J'aimerais, lorsque cela arrive, éviter d'avoir directement la fenêtre poppup "Unhandled exception" afin de pouvoir créer une archive avec le contexte de mon application au moment du plantage.

J'ai déjà une fonction qui permet de zipper le core du programme. Mon problème consiste à appeler cette fonction avant le plantage.

Je pensais qu'en surchargeant la méthode : ProcessWndProcException de CWinApp je pourrais faire des traitement particuliers. Or il semblerait qu'en cas de plantage je ne passe pas dans cette fonction. Que dois-je faire? Y a t'il une fonction particulière à utiliser? Existe -il une autre méthode pour faire ce que je souhaite?

Merci.
06/12/2006, 10h03
Médinoc

ProcessWndProcException() ne marche que pour les exceptions survenues dans le traitement d'un message, pas dans l'initialisation.
D'ailleurs, on dirait ce n'est que pour les exceptions C++, pas les exceptions Win32 que ton code déclenche.

Pour ça, je pense que tu devrais plutôt utiliser le SEH. Un gros __try {} __except() {} dans le InitInstance(), un dans le Run(), etc...

PS: Pour les pointeurs, on dit NULL, pas 0. Le C++ a beau avoir #define NULL 0 sous Visual, NULL est quand même plus explicite pour le lecteur...

heu...

C'est ce que j'avais au début, mais sans doute mal :(

Ma fonction InitInstance :

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
 
 
/////////////////////////////////////////////////////////////////////////////
// CMITApp initialization
 
BOOL CMITApp::InitInstance()
{
 
  AfxEnableControlContainer();
 
	// Standard initialization
	// If you are not using these features and wish to reduce the size
	//  of your final executable, you should remove from the following
	//  the specific initialization routines you do not need.
#ifdef _AFXDLL
	Enable3dControls();			// Call this when using MFC in a shared DLL
#else
	Enable3dControlsStatic();	// Call this when linking to MFC statically
#endif
 
  __try
  {
	  CMITDlg dlg;
	  m_pMainWnd = &dlg;
 
	  int nResponse = dlg.DoModal();
	  if (nResponse == IDOK)
	  {
		  // TODO: Place code here to handle when the dialog is
		  //  dismissed with OK
	  }
	  else if (nResponse == IDCANCEL)
	  {
		  // TODO: Place code here to handle when the dialog is
		  //  dismissed with Cancel
	  }
  }
  __except(SauvegarderContexte(GetExceptionInformation(),"WinMain"),1)
  {
    // Ne rien faire ici
  }
 
	// Since the dialog has been closed, return FALSE so that we exit the
	//  application, rather than start the application's message pump.
	return FALSE;
}

et voici la réponse de Visual à la compilation :

warning C4509: nonstandard extension used: 'InitInstance' uses SEH and 'dlg' has destructor
see declaration of 'dlg'
Cannot use __try in functions that require object unwinding
Error executing cl.exe.

06/12/2006, 10h21
Matthieu Brucher

Regarde plutôt du côté de SetUnhandledExceptionFilter -> dbghelp.dll

Ou pour corriger l'erreur elle-même, essaie en plaçant tes opérations sur dlg dans une autre fonction, que tu appelles.
Ce code devrait en théorie compiler :

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
 
/////////////////////////////////////////////////////////////////////////////
// CMITApp initialization
 
BOOL CMITApp::InitInstance()
{
 
	AfxEnableControlContainer();
 
	// Standard initialization
	// If you are not using these features and wish to reduce the size
	//  of your final executable, you should remove from the following
	//  the specific initialization routines you do not need.
	#ifdef _AFXDLL
	Enable3dControls();			// Call this when using MFC in a shared DLL
	#else
	Enable3dControlsStatic();	// Call this when linking to MFC statically
	#endif
 
	__try
	{
		AfficherDialogPrincipale();
	}
	__except(SauvegarderContexte(GetExceptionInformation(),"WinMain"),1)
	{
		// Ne rien faire ici
	}
 
	// Since the dialog has been closed, return FALSE so that we exit the
	//  application, rather than start the application's message pump.
	return FALSE;
}
 
//Penser à déclarer cette fonction dans la classe CMITApp
void CMITApp::AfficherDialogPrincipale(void)
{
	CMITDlg dlg;
	m_pMainWnd = &dlg;
 
	int nResponse = dlg.DoModal();
	if (nResponse == IDOK)
	{
		// TODO: Place code here to handle when the dialog is
		//  dismissed with OK
	}
	else if (nResponse == IDCANCEL)
	{
		// TODO: Place code here to handle when the dialog is
		//  dismissed with Cancel
	}
}

Il y a quelques incompatibilités entre le SEH et C++ : Entre autres, on ne peut pas utiliser les deux dans la même fonction, et nous venons donc d'en découvrir une autre: On ne peut pas utiliser le SEH dans une fonction qui devra invoquer des destructeurs.

06/12/2006, 10h47
Médinoc

Je viens de regarder SetUnhandledExceptionFilter(), ça a l'air mieux.
06/12/2006, 11h05
Matthieu Brucher

Citation:

Envoyé par Médinoc

Je viens de regarder SetUnhandledExceptionFilter(), ça a l'air mieux.

C'est surtout LA solution sous Windows en cas de plantage d'une application.
06/12/2006, 11h15
Aradesh

Je viens de tester la solution proposée par Medinoc (à savoir faire une autre fonction). Ca marche et je récupère bien les "erreurs" comme il faut.

Deux questions demeurent pour le néophyte que je suis.

Tout d'abord en utilisant la méthode du "try" "catch" n'est-il pas suffisant de le faire dans le InitInstance de la classe d'application? Pourquoi faut-il le faire aussi dans Run()?

En quoi la méthode : SetUnhandledExceptionFilter est elle préférable?
(Ca m'a l'air plus compliqué à mettre en place :( )
06/12/2006, 11h18
Médinoc

Citation:

Envoyé par Aradesh

Tout d'abord en utilisant la méthode du "try" "catch" n'est-il pas suffisant de le faire dans le InitInstance de la classe d'application? Pourquoi faut-il le faire aussi dans Run()?

Dans une application Dialog-Based, tu n'en as pas besoin: Tout est fait dans le InitInstance().

Citation:

En quoi la méthode : SetUnhandledExceptionFilter est elle préférable?
(Ca m'a l'air plus compliqué à mettre en place :( )

Parce qu'elle chopera TOUTE exception non-interceptée, où qu'elle survienne.
06/12/2006, 11h27
Matthieu Brucher

Citation:

Envoyé par Aradesh

En quoi la méthode : SetUnhandledExceptionFilter est elle préférable?
(Ca m'a l'air plus compliqué à mettre en place :( )

C'est celle qui est utilisée lors d'un plantage irrécuoérable de la machine.
C'est plus difficile à mettre en place, mais je suis en cours de rédaction d'un tuto là-dessus.
06/12/2006, 16h03
Aradesh

Ca marche :D

J'ai essayé la solution avec la méthode SetUnhandledExceptionFilter et ça marche!!! Merci bien :mrgreen:

Par contre, cela ne permet pas de récupérer les "assertions failure". Y a t'il un moyen de les récupérer tout comme les plantages???
08/12/2006, 09h34
Aradesh

Heu... pour mon dernier petit problème j'ai crée une nouvelle classe qui hérite de celle qui fait les ASSERT et j'ai redéfini cette macro pour qu'elle fasse autre chose... Bref j'ai bidouillé

Pour le reste, merci beaucoup, ça marche très bien, j'aurais eu du mal sans votre aide.

MERCI !!! :mouarf: :mouarf:
07/04/2008, 11h39
louf99

Tu pourrais pas mettre du code qui nous montre comment tu as fait ? histoire de conclure ce post correctement.

Merci !