Discussion :

[StormimOn]

Bonjour,

Je suis confronté à un problème qui m'ennuie légèrement. Lorsque je quitte une application après avoir affiché un fichier PDF dans un WebBrowser, j'ai l'erreur suivante : blablabla ... la mémoire ne peut être read

J'ai réussi à reproduire l'erreur sur un exemple très simple (cf. le code ci-dessous). Une form avec 2 boutons : le premier charge un PDF dans un WebBrowser, le second permet de quitter l'application.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public partial class Form1 : Form
{
    public Form1()
    {
        InitializeComponent();
    }
 
    private void button1_Click(object sender, EventArgs e)
    {
        using (Form2 f = new Form2())
        {
            f.ShowDialog();
        }
    }
 
    private void button2_Click(object sender, EventArgs e)
    {
        this.Close();
    }
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
public partial class Form2 : Form
{
    public Form2()
    {
        InitializeComponent();
    }
 
    private void Form2_Shown(object sender, EventArgs e)
    {
        webBrowser1.Navigate(@"X:\Truc\Machin\MonSuperFichier.pdf");
    }
}

Il suffit de cliquer sur le 1er bouton, fermer la fenêtre du WebBrowser une fois le PDF chargé et pour finir cliquer sur le 2nd bouton dans la foulée. On tombe alors sur le message d'erreur.

Sachant que :
- en lançant l'application depuis Visual Studio il n'y a pas cette erreur
- en fermant l'application directement après le ShowDialog, il n'y a pas l'erreur non plus
- testé avec Adobe Reader 9, il faudrait que je vois avec les autres versions

Si certains savent d'où cela peut venir, ça m'intéresse., sachant que la solution de rechange c'est de charger le PDF directement avec Adobe Reader.

[flzox]

Salut,
J'ai exactement le même soucis.
As-tu trouvé une solution ?

[flzox]

Si quelqu'un n'aurait ne serait-ce qu'une idée ou une suggestion, je suis preneur ...

Merci

[StormimOn]

Je n'ai toujours pas trouvé de solution pour ce problème, à part charger le PDF dans Adobe Reader. Mais ce n'est pas pratique pour ce que je veux malheureusement.

[StormimOn]

A priori, il semblerait que ce problème soit uniquement présent avec la version 9 de Adobe Reader et Windows XP. J'ai testé sur une version 8 et je n'ai pas eu de souci et avec la version 9 sous Vista cela fonctionne très bien aussi.

[soulkiller]

Bonjour,
je me frotte au même problème actuellement avec obligation de le résoudre rapidement.

Je pense que le souci vient du fait que c# dispose le webrowser à la fermeture mais Adobe reader n'est pas encore fermé à ce moment la. Il essaie donc de lire quelque chose sur un segment qui n'existe plus.

J'ai essayé plusieurs choses notamment :
- de charger une page vide avant de fermer la fenêtre
- de faire un Stop() pour arrêter le browser
- de laisser un délai
- de détruire l'instance du webrowser à la main ( = null)

rien de cela ne fonctionne.

Je vais tenter via ActiveX directement sans passer par le webbrowser.
Apparement, il y'aurait aussi un effet de bord a cette méthode qui serait la compatibilité entre versions de Adobe reader. Donc il faudra embarquer l'installeur de adobe ou mettre a jour l'appli avec chaque version.
J'ai plus les sources a citer désolé... trop de pages lues.
Qui plus est, rien ne dit que cela resoudra le problème.

Autre piste, j'avais pensé a lancer le webrowser dans un autre thread ou appdomain et de le détruire sur le onClosing avec un bon gros try/catch.

De votre côté, avez-vous progressé ?

[soulkiller]

J'étais pas loin.
Il semblerait que cela soit bien une question de temps de fermeture....

j'avais juste pas été assez loin.
C'est ce post qui m'a poussé faire un essai.

http://groups.google.com/group/adobe...lnk=raot&pli=1

Contrairement a lui (dernier post), je n'ai pas eu besoin du panel car le webbrowser est déjà un container. Par contre je pense que le temps requis est variable fonction de la machine, de sa charge et potentiellement de la taille du fichier.(et de la météo ?)

J'ai testé sur mon dual core 2.4, ca met 3 s. Sur ma vmware il en fautentre 5 et 10 ....
Donc j'ai opté pour un Hide de la forme avec 10s de délai histoire que ca passe partout ou adobe reader 9 peut tourner.

C'est juste un workarround, c'est loin d'être esthétique, mais ca marche.

En regardant de plus près le composant de Adobe, je me demande si le event HandleDestroyed est triggered au bon moment... je vais tester et je vous dirais. J'aime pas les bidouilles dans mon code ^^

pour résumer :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
        private void Form1_FormClosing(object sender, FormClosingEventArgs e)
        {
            this.Hide();
            this.Controls.Remove(webBrowser1);
            System.Threading.Thread.Sleep(10000);
        }

[soulkiller]

Bonjour,

Suite et fin de ma recherche a ce sujet.

j'ai creuse du cote du composant adobe et j'ai une solution qui marche.
En fait le composant activeX ne se decharge pas tout seul.
La raison est que l'implementation du composant d'adobe 9 n'exporte pas la fonction DllCanUnload donc plus on charge de pdf successivement et plus le handle est incremente.
Voici donc un chti bout de code qui fait le boulot.
Il cherche tous les modules du processus courant contenant AcroPDF ou AcroRd et les decharge.

Attention, cela ne tiens la route que si garder les dll chargees dans l'application durant toute l'execution ne vous gene pas. Sinon il vous faudra aussi les recharger a la main.


je l'appelle sur le Form_closing a titre indicatif.

En esperant que cela vous aide :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
 
[DllImport("kernel32.dll", EntryPoint = "GetModuleHandle")]
static extern int GetModuleHandle([MarshalAs(UnmanagedType.LPStr)] string lpModuleName);
 
 
[DllImport("kernel32.dll", EntryPoint = "FreeLibrary")]
static extern bool FreeLibrary(int hModule);
 
        void UnloadAdobe()
        {
            Process a = Process.GetCurrentProcess();
 
            bool foundone = true;
            while (foundone)
            {
                foundone = false;
                ProcessModuleCollection ObjModules = a.Modules;
 
                // Iterate through the module collection.
                foreach (ProcessModule objModule in ObjModules)
                {
                    // find acrobat PDF "AcroPDF" in program files
                    if (objModule.ModuleName.Contains(@"AcroPDF")  || objModule.ModuleName.Contains(@"AcroRd"))
                    {
                        foundone = true;
                        int handle = GetModuleHandle(objModule.ModuleName);
                        if (handle != 0)
                            FreeLibrary(handle);
                    }
                }
            }
        }

[flzox]

Salut,
merci beaucoup pour ta solution.

Cependant j'ai un petit soucis. Le programme plante lorsque objModule.ModuleName = "AcroRd32.dll".

L'appelle de FreeLibrary(handle) fait planter l'application (le handle est bien != 0)

[soulkiller]

Bonjour,
J'ai rencontre ce probleme uniquement sous vista.
est-ce egalement ton cas ?

Il semblerait que vista gere mieux le dechargement et que ce code ne soit pas necessaire contrairement a XP.
je verifie simplement la version du systeme au moment de l'appel.

Depuis plus de message d'erreur ni sur XP ni sur Vista
En esperant que cela regle ton souci.

[flzox]

Bonjour,
j'ai en effet pensé que le problème était simplement du à XP donc je n'exécute ce petit bout de code que si je détecte que le système est XP. Mais, car il y a toujours un "mais", je viens d'apprendre que sur certain postes équipés de windows xp qui n'avaient pas le problème à l'origine, ce petit bout de code est exécuté et fait planter l'appli (impossible de la fermer).

Comment se fait-il qu'un Freelibrary appelé sur un handle != 0 provoque un plantage ? (objModule.ModuleName = "AcroRd32.dll")

Edit : le message d'erreur est : "vshost.exe à cessé de fonctionner", et le bloque try / catch ne capte pas l'exception

[flzox]

Pensez-vous que ceci est du au fait que le compteur de référence est déjà = 0.

Si oui est-il possible par un moyen ou un autre de faire un test sur le nombre de références avant d'appeler FreeLibrary ?

[flzox]

La solution consistant à supprimer le control parent du composant Adobe:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
private void Form1_FormClosing(object sender, FormClosingEventArgs e)
{
  this.Hide(); 
  this.Controls.Remove(webBrowser1);
  System.Threading.Thread.Sleep(10000);
}

non content d'être une affreuse bidouille, ne fonctionne pas chez moi. Enfin si, aléatoirement, 2 fois sur 3 et quelque soit la durée du Thread.Sleep.

Help ...