[.NET] Error na 256 processed bestanden in recursive loop*

[eendje001]

Na een terecht slotje op mijn vorige poging, bij deze een aangepaste/verduidelijkte versie...

Ik ben inmiddels een tijd bezig met het automatisch laten genereren van thumbnails voor een grote collectie aan pdf-bestanden. Hiervoor heb ik in visual studio 2k5 een tooltje gebouwd dat recursive vanuit een startdirectory alle pdf bestanden afloopt, en hier een thumbnail voor maakt.

Nu werkt het programma prima, en genereert het naar hartelust thumbnails, maar geeft het consequent na 256 files de brui eraan, met een filenotfound exception (zie hieronder voor de exacte foutmelding). Als hierna het programma weer gestart wordt gaat hij rustig verder waar hij gebleven is, dus een fout in een specifiek bestand is het ook niet.
Aangezien 256 natuurlijk in de digitale wereld een zeer kenmerkend getal is, vermoed ik dat het ergens tegen een grens aanloopt. Ik zie inmiddels echter door de bomen het bos niet meer, en google helpt mij ook niet meer verder.

Wat heb ik al geprobeerd:
Debugging - het programma compileert prima, en ook de debug opties geven geen foutmeldingen terug. Op zich is dit ook niet vreemd, aangezien hij succesvol 256 keer door de loop gaat.
Foutzoeken - Alle routines die uit te schakelen zijn zonder invloed te hebben op het primaire proces (het genereren van de thumbnail) uitgeschakeld, en wederom het builden/debuggen proces in. Ook dit mocht niets baten, en hij blijft na 256 processed files eruit klappen.
Zoeken via google - Ook hier na bijna een week zoeken en proberen geen resultaten. Nergens kan ik een referentie vinden aan de limiet waar hij tegen aan lijkt te lopen. Bevriende programmeurs benaderen heeft helaas ook niet gebaat.

Waar denk ik zelf dat het in kan zitten (alhoewel ik daar geen bevestiging over kan vinden)

• Een limiet in het openen en sluiten van acrobat instanties binnen een enkele thread o.i.d
• Een variabele die niet losgelaten wordt, en dus 'volloopt'
• Een grens in het schrijven van bestanden

De foutmelding die hij geeft:
System.IO.FileNotFoundException: Unable to find the specified file.
at PDFThumbnail.PDFThumbnail.DirSearch(String sDir)

Elke hulp/hint in de goede richting is welkom, ik kom er inmiddels echt niet meer uit.

De specifieke code voor de recursive loop (rest is eruit geknipt):

Visual Basic .NET:

Sub DirSearch(ByVal sDir As String)

' ...hoop declaraties

' start van de loop
Try 

            ' Get list of files to process from the startdir for the first run 
            ' Second and further runs use dir from its own recursive process 
            For Each d In Directory.GetDirectories(sDir) 
                For Each f In Directory.GetFiles(d, "*.pdf")

                      '  ... Veel replaces, en dan het daadwerkelijk aanroepen van acrobat, en het bestand openen
                        pdfDoc = CreateObject("AcroExch.PDDoc") 
                      ret = pdfDoc.Open(inputFile) 

                           ' ... heleboel dingen doen met de eerste pagina van de pdf

                           ' en verder met het afsluiten van de pdf objects
                           thumbnailGraphics.Dispose() 

                            pdfDoc.Close() 
                            Marshal.ReleaseComObject(pdfPage) 
                            Marshal.ReleaseComObject(pdfRect) 
                            Marshal.ReleaseComObject(pdfDoc) 

               Next 

                ' After all files in current dir have been processed, passing on 
                ' Next dir to process. 
                DirSearch(d) 
            Next 

        End Try

[Daos]

Ik wil je wel wat tipjes geven:
- Zorg ervoor dat functies niet langer zijn dan 30 regels (en hooguit 80 karakters breed). Een functie van 150 regels is lastig te begrijpen/debuggen.
- Een groot try-blok heeft meestal niet zoveel nut.
- 256 kan komen van het maximum aantal bestanden dat tegelijkertijd open kan staan. pdfDoc.Close() staat in een if-statement terwijl pdfDoc.Open(inputFile) altijd gebeurt.

[Verwijderd]

Zet die COM objecten 's expliciet op Nothing als je ze niet meer gebruikt? Daarmee verlaag je de reference counter, en weet het object wanneer 'ie zichzelf op moet ruimen. Of Marshal.ReleaseComObject dat ook (altijd goed) doet weet ik niet zeker.

[RobIII]

eendje001 schreef op maandag 11 december 2006 @ 19:30:
Wat heb ik al geprobeerd:
Debugging - het programma compileert prima, en ook de debug opties geven geen foutmeldingen terug. Op zich is dit ook niet vreemd, aangezien hij succesvol 256 keer door de loop gaat.

Dat het compileert en geen fouten geeft wil niet zeggen dat er iets mis kan zijn met de logica an sich ofzo. Het kan dus goed pas na 256 keer fout gaan

Ter illustratiie:

Visual Basic .NET:

        Dim T As Integer = 5

        While T >= 0
            Console.WriteLine("10 gedeeld door {0} = {1}", T, 10 \ T)
            T -= 1
        End While

De logica in dit voorbeeld is prima in orde, het compileert en geen enkele warning whatsoever en toch krijg je een division by zero

eendje001 schreef op maandag 11 december 2006 @ 19:30:
Foutzoeken - Alle routines die uit te schakelen zijn zonder invloed te hebben op het primaire proces (het genereren van de thumbnail) uitgeschakeld, en wederom het builden/debuggen proces in. Ook dit mocht niets baten, en hij blijft na 256 processed files eruit klappen.

Dat is niet helemaal waar; maar da's dan ook de kunst van het debuggen
Als ik je code uitkleed tot op de bare-essentials als volgt:

Visual Basic .NET:

    Sub DirSearch(ByVal sDir As String)
        Dim d As String
        ' start van de loop

        ' Get list of files to process from the startdir for the first run 
        ' Second and further runs use dir from its own recursive process 
        For Each d In Directory.GetDirectories(sDir)
            'For Each f In Directory.GetFiles(d, "*.*")
            'Next
            Console.WriteLine(d)
            DirSearch(d)
        Next
    End Sub

..dan blijkt je lus prima te werken; het probleem zit 'm dus ergens anders. Met debuggen hebben we het over breakpoints zetten, tussentijdse waardes monitoren of afdrukken/loggen etc.

Mijn vermoeden zit 'm ook in een reference counter die over de flos gaat na 255+ objecten; wat dat betreft is Afterlife's tip helemaal zo gek nog niet, evenals Daos's 3e tip

[ Voor 8% gewijzigd door RobIII op 11-12-2006 21:04 ]

[eendje001]

Bedankt voor de tips, meteen even geprobeerd:
- pdfDoc.Close() verplaatst naar buiten het if-statement, nu vindt het plaats op hetzelfde nivo als de open functie. Builden/debuggen/runnen geeft echter nog steeds dezelfde foutmelding

- De COM objecten expliciet naar Nothing gezet, hielp helaas ook niet. Wel even geprobeerd of de code die ze vrijgeeft uberhaupt aangeroepen wordt, en deze wordt wel gewoon uitgevoerd bij elke run.

- Het try blok is inderdaad nogal groot, maar volgens mij zou het niet uit moeten maken voor de error. Toch even het try deel eruit gehaald, en de foutmelding treedt nog steeds op, alleen wordt hij nu niet meer netjes afgevangen.

- De functies kan ik niet heel makkelijk opsplitsen, maar als ik alle niet-essentiele functies eruit haal zijn ze een stuk korter, en dat mocht zoals in de startpost al gezengd helaas ook niet baten.

Ik ga in deze lijn in ieder geval nog even verder puzzelen, maar verdere suggesties zijn meer dan welkom...

[RobIII]

eendje001 schreef op maandag 11 december 2006 @ 19:30:

Visual Basic .NET:

'  ... Veel replaces, en dan het daadwerkelijk aanroepen van acrobat, en het bestand 

Overigens; gezien de "System.IO.FileNotFoundException": Weet je wel 100% zeker dat de file bestaat? Zeker met al die replace's e.d. kon het wel eens mis gaan ergentwo Console.writeline de filename waarde eens

[ Voor 34% gewijzigd door RobIII op 11-12-2006 21:13 ]

[eendje001]

RobIII schreef op maandag 11 december 2006 @ 21:11:
[...]


Overigens; gezien de "System.IO.FileNotFoundException": Weet je wel 100% zeker dat de file bestaat? Zeker met al die replace's e.d. kon het wel eens mis gaan ergentwo Console.writeline de filename waarde eens

Ik weet zeker dat de file bestaat, ook getuige het feit dat, bij een volgende run van het programma, hij keurig bij dat bestand waar hij vorige keer op stukliep weer begint.

Dit laat hij ook zien in de console als ik de volgende regel aan het einde zet:

Visual Basic .NET:

Console.WriteLine("Generated thumbnail... {0}", outputFile)

[RobIII]

eendje001 schreef op maandag 11 december 2006 @ 21:18:
[...]


Ik weet zeker dat de file bestaat, ook getuige het feit dat, bij een volgende run van het programma, hij keurig bij dat bestand waar hij vorige keer op stukliep weer begint.

Dit laat hij ook zien in de console als ik de volgende regel aan het einde zet:

Visual Basic .NET:

Console.WriteLine("Generated thumbnail... {0}", outputFile)

Dan zou ik het toch gaan zoeken in dat COM gebeuren; ik moet eerlijk bekennen niet zo heel erg bekend te zijn met COM i.c.m. .Net (dude, wat een acroniemen ) maar er hangt me wel iets van bij dat het wat beperkingen heeft

WOEI

[ Voor 5% gewijzigd door RobIII op 11-12-2006 22:12 ]

[eendje001]

RobIII schreef op maandag 11 december 2006 @ 21:19:
[...]

Dan zou ik het toch gaan zoeken in dat COM gebeuren; ik moet eerlijk bekennen niet zo heel erg bekend te zijn met COM i.c.m. .Net (dude, wat een acroniemen ) maar er hangt me wel iets van bij dat het wat beperkingen heeft

Dan ga ik daar maar verder in graven, bedankt voor alle hulp tot nu toe

[RobIII]

Ik zit nog eens even in de code ( ) te kijken... dude; het stikt van de ranzigheden
Even wat puntjes:

Why in the H*ll gebruik je de "xor methode" om 2 vars te swappen? Bang dat je een var teveel moet declareren? Kost echt niet veel hoor; zo'n integertje Doe nou maar gewoon, dat maakt je code stukken leesbaarder i.p.v. dat je op de "haxx0r" manier gaat zitten swappen.

Daarnaast zie ik dat er gebruik wordt gemaakt van 't clipboard; nu ken ik de Acrobat objecten niet; maar is er echt geen andere manier dan via het clipboard gaan? Als ik dit zou gebruiken op mijn PC en mijn clipboard is opeens leeg/overschreven dan krijg je ruzie met me

Dan zie ik je praten over een "strange bug in pdfPage.GetSize". Weet je zeker dat die functie een (PDF)Rect teruggeeft dan? Lijkt me stug dat zoiets eenvoudigs een "bug" bevat.

Ik vermoed nog steeds een refcounter probleem, of een of ander vet memory lek in of jouw code, of die van Adobe

[ Voor 12% gewijzigd door RobIII op 11-12-2006 22:25 ]

[eendje001]

RobIII schreef op maandag 11 december 2006 @ 22:24:
Ik zit nog eens even in de code ( ) te kijken... dude; het stikt van de ranzigheden

Hehe, kan best kloppen, dit is volgens mij het eerste project dat ik ooit tot een build stadium heb gebracht, dus echt ervaren kan je me inderdaad niet noemen

Even wat puntjes:

Why in the H*ll gebruik je de "xor methode" om 2 vars te swappen? Bang dat je een var teveel moet declareren? Kost echt niet veel hoor; zo'n integertje Doe nou maar gewoon, dat maakt je code stukken leesbaarder i.p.v. dat je op de "haxx0r" manier gaat zitten swappen.

Aangezien deze routine nogal wat problemen gaf bij directories waar veel landscape en portrait bestanden door elkaar stonden heb ik deze inmiddels vervangen door separate waardes dmv:

Visual Basic .NET:

If (pdfRectTemp.x < pdfRectTemp.y) Then
      templateFile = templatePortraitFile
      With appSettings
         thumbnailWidth = .GetValue("thumbnailWidthPortrait", GetType(Integer))
         thumbnailHeight = .GetValue("thumbnailHeightPortrait", GetType(Integer))
      End With
Else
      templateFile = templateLandscapeFile
      With appSettings
         thumbnailWidth = .GetValue("thumbnailWidthLandscape", GetType(Integer))
         thumbnailHeight = .GetValue("thumbnailHeightLandscape", GetType(Integer))
      End With
End If

Ook vrij ranzige code waarschijnlijk, maar dit werkte in ieder geval zonder problemen.

Daarnaast zie ik dat er gebruik wordt gemaakt van 't clipboard; nu ken ik de Acrobat objecten niet; maar is er echt geen andere manier dan via het clipboard gaan? Als ik dit zou gebruiken op mijn PC en mijn clipboard is opeens leeg/overschreven dan krijg je ruzie met me

Jup, dat snap ik volledig, resizen ziet er alleen vele malen beter uit op deze manier, anders werden de images nogal 'fuzzy'. Ik zal het in ieder geval in de notes even toevoegen dat het gebeurt

Dan zie ik je praten over een "strange bug in pdfPage.GetSize". Weet je zeker dat die functie een (PDF)Rect teruggeeft dan? Lijkt me stug dat zoiets eenvoudigs een "bug" bevat.

Is inderdaad niet echt een bug, meer een foutje in de documentatie van adobe, zal de tekst wat parafraseren, het idee dat er wat extra waarden meegegeven moeten worden is wel duidelijk neem ik aan.

Ik vermoed nog steeds een refcounter probleem, of een of ander vet memory lek in of jouw code, of die van Adobe

Het memorygebruik blijft mooi binnen perken, als ik het geheugengebruik volg tijdens het proces, zie ik dat keurig het geheugen uit eerdere runs vrijgegeven lijkt te worden. Het geheugengebruik van het acrobat proces komt in ieder geval nooit hoger dan wanneer ik normaal de pdf bestanden zou openen. Kortom, Ik kom elke keer toch ook uit op een refcounter probleem.
Verder browsen en googlen hierop kom ik uit op diverse artikelen met problemen met de releasecomobject in structuren als deze. Oplossingen worden er echter niet echt in geboden.

Zie bijvoorbeeld: http://blogs.msdn.com/cbrumme/archive/2003/04/16/51355.aspx

[whoami]

Daos schreef op maandag 11 december 2006 @ 19:33:
Ik wil je wel wat tipjes geven:
- Zorg ervoor dat functies niet langer zijn dan 30 regels (en hooguit 80 karakters breed). Een functie van 150 regels is lastig te begrijpen/debuggen.

Sorry, maar dit vind ik zever.

- 256 kan komen van het maximum aantal bestanden dat tegelijkertijd open kan staan. pdfDoc.Close() staat in een if-statement terwijl pdfDoc.Open(inputFile) altijd gebeurt.

Dit zou misschien wel kunnen. Zowiezo zou het het beste zijn als je ervoor zorgt dat je file altijd gesloten wordt, door de Close in een finally block te plaatsen.

Daarmee verlaag je de reference counter, en weet het object wanneer 'ie zichzelf op moet ruimen. Of Marshal.ReleaseComObject dat ook (altijd goed) doet weet ik niet zeker.

Dat doet ie afaik wel ja.

TS: plaats anders eens een breakpoint met een conditie zodanig dat die slechts na 255 iteraties breakt, en loop dan eens stap voor stap door de code. Kijk ook eens wat de innerexception is.

[ Voor 23% gewijzigd door whoami op 12-12-2006 09:03 ]

[CodeIT]

Nog één opmerking, waarom gebruik je een recursieve functie?
Als je de volgende code gebruikt krijg je alle files in de directory en subdirectories terug:

Visual Basic .NET:

Dim dirInf As New IO.DirectoryInfo(sDir)
For Each fileInf As IO.FileInfo In dirInf.GetFiles("*.pdf", IO.SearchOption.AllDirectories)
       'iets met thumbnails...
Next

[TeeDee]

Er zijn trouwens een heel stuk 'snellere' librarys om dit aan te vallen. iTextSharp is erg snel. (Nadeel is de crappy documentatie).

Ik heb hiermee een tooltje gebouwd om meerdere PDF's te mergen op hogeresolutie. Dit heeft +/- 40 sec. over 1000 PDF's gedaan.

Ik denk dat je dat ook aardig wat calls naar Acrobat zelf zal schelen.

[Daos]

whoami schreef op dinsdag 12 december 2006 @ 09:01:
[...]
Sorry, maar dit vind ik zever.

Mijn ervaring is dat lange functies slecht te debuggen zijn omdat je niet snel ziet wat de functie allemaal doet. Bovendien kan je kleinere functies vaak afzonderlijk testen en/of gebruiken in testen. Ongeveer 30 regels vind ik het makkelijkst om mee te werken.
De breedte heeft vooral invloed op het printen. Bij code van 80 karakter breed past alles mooi op een A4.


In dit geval zou ik de conversie van een pdf-bestand in aparte functie gedaan hebben (met input- en misschien ook de output-bestandsnaam als argument). Waarschijnlijk zou ik de conversie zelf ook nog gesplitst hebben.

Ik dacht bijvoorbeeld dat de bug kwam doordat de bestanden open blijven staan na de conversie. Als dit zo is, dan gaat het ook fout als je met hetzelfde bestand twee keer de conversie doet.
Zoiets is nu niet makkelijk te implementeren/testen. De testcode zal tussen de echte code komen te staan.
Als de echte code in kleinere functies was verdeeld, dan zou je gewoon de conversie-functie 2 keer aan kunnen roepen met dezelfde input- en verschillende output-bestandsnamen. De testcode staat mooi los van de echte code. Je hoeft dus niet bang te zijn dat je bij het testen per ongeluk je echte code sloopt. Bovendien kan je ook de testcode bewaren om later te kijken of je niets gesloopt hebt (regressietest).

[.oisyn]

Daos schreef op dinsdag 12 december 2006 @ 15:50:
De breedte heeft vooral invloed op het printen. Bij code van 80 karakter breed past alles mooi op een A4.

Wie print er in hemelsnaam z'n code, anders dan de student die z'n code af en toe op papier moet inleveren

[Eskimootje]

.oisyn schreef op dinsdag 12 december 2006 @ 16:13:
[...]

Wie print er in hemelsnaam z'n code, anders dan de student die z'n code af en toe op papier moet inleveren

Ik print het altijd als backup

Maar nee precies 80 karakters is imho onzin, de IDE omgeving moet dusdanig instelbaar zijn zodat iedereen zijn eigen prettige formaat kan lezen. Daarnaast kun je in de meeste IDE's ook gewoon je print instellingen aanpassen.

[megamuch]

.oisyn schreef op dinsdag 12 december 2006 @ 16:13:
[...]

Wie print er in hemelsnaam z'n code, anders dan de student die z'n code af en toe op papier moet inleveren

Ik als ik heel erg lang aan het kloten ben en er echt niet meer uit kom. Dan ga ik ff in de denkhouding (benen op bureau etc) en even rustig lezen @ papier.

[eendje001]

CodeIT schreef op dinsdag 12 december 2006 @ 09:48:
Nog één opmerking, waarom gebruik je een recursieve functie?
Als je de volgende code gebruikt krijg je alle files in de directory en subdirectories terug:

Visual Basic .NET:

Dim dirInf As New IO.DirectoryInfo(sDir)
For Each fileInf As IO.FileInfo In dirInf.GetFiles("*.pdf", IO.SearchOption.AllDirectories)
       'iets met thumbnails...
Next

Op zich lijkt me het fijn om van de recursive function af te zijn. Met deze code kan ik echter geen replace doen, aangezien de variabelen niet meer naar string te converteren zijn.
Ik wil nl het volgende onder andere doen voor elke file:

Visual Basic .NET:

Dim inputFile As String = f
Dim outputFile As String = f.ToString.Replace(d, jpgOutputPath).Replace(".pdf", ".jpg")

Dit gaat dus helaas niet.

[TeeDee]

Wat gaat dan niet? Krijg je een foutmelding?

Visual Basic .NET:

f.Replace(".pdf",".jpg") 'weet niet wat die andere waardes doen....

zou imo gewoon moeten werken. Ik zie niet waarom je f nog een keer naar een string moet casten.

[eendje001]

whoami schreef op dinsdag 12 december 2006 @ 09:01:
TS: plaats anders eens een breakpoint met een conditie zodanig dat die slechts na 255 iteraties breakt, en loop dan eens stap voor stap door de code. Kijk ook eens wat de innerexception is.

Dit gedaan, en meteen even wat andere dingen geprobeerd.
Wat valt op: Als het hele thumbnail proces weghaal, en hem alleen het document laat openen en hiervan het aantal pagina's laat geven, gaat het goed, hij loopt alle dirs door, en geeft resultaat voor alle bestanden.
Laat ik hem vervolgens ook de eerste pagina openen (met pdfPage = pdfDoc.AcquirePage(0)), dan klapt hij eruit na 256 bestanden. Dit ondanks dat ik keurig de ReleaseComObject aanroep op deze twee.
De code bestaat op dat moment alleen nog uit de recursive loop, en deze twee acties. Heel veel gebeurt er dus niet meer, en het foutzoeken is daarmee dus ook erg gelimiteerd.

Het kan dus eigenlijk alleen nog maar zo zijn dat de refcounter voor een van deze twee dichtloopt, waarbij dat vermoedelijk is voor de acquirepage. Veel verder met het geforceerd afsluiten/dumpen hiervan kom ik echter niet.

[whoami]

En welke exceptie krijg je dan ? En wat is de inner-exception ?
Test je altijd op dezelfde directory ? Klapt hij er altijd uit op dezelfde file, of niet ? Kan het dan niet zijn dat er iets met die file schort ?

[CodeIT]

eendje001 schreef op dinsdag 12 december 2006 @ 17:17:
[...]


Op zich lijkt me het fijn om van de recursive function af te zijn. Met deze code kan ik echter geen replace doen, aangezien de variabelen niet meer naar string te converteren zijn.
Ik wil nl het volgende onder andere doen voor elke file:

Visual Basic .NET:

Dim inputFile As String = f
Dim outputFile As String = f.ToString.Replace(d, jpgOutputPath).Replace(".pdf", ".jpg")

Dit gaat dus helaas niet.

Dat kan heel goed kloppen Je kan de filename echter wel gewoon uit het IO.FileInfo halen

Visual Basic .NET:

Dim dirInf As New IO.DirectoryInfo(sDir) 
For Each fileInf As IO.FileInfo In dirInf.GetFiles("*.pdf", IO.SearchOption.AllDirectories) 
       dim fileName as string = fileInf.FullName 'tadaa
Next

Je kan aan een IO.FileInfo ook zijn path ed opvragen. Lijkt me in jouw geval ideaal om van je recursieve functie af te komen.

[ Voor 6% gewijzigd door CodeIT op 12-12-2006 19:39 ]

[PhysicsRules]

Wat m opvalt is :

Visual Basic .NET:

 Dim ret As Integer
    ' Open the document
    ret = pdfDoc.Open(inputFile)

    If ret = False Then
        Throw New FileNotFoundException
    End If

Ik ben meer van de C#, maar daar zou dit niet compileren: een boolean met een int vergelijken. Misschien dat VB.Net dit impliciet cast, maar daar zou ik niet op vertrouwen.

Edit:
Geïntrigeerd door je probleem heb ik je project gedownload en uitgeprobeerd. Behalve dat het me wat moeite kostte om de juiste instellingen te maken (die heb je niet meegeleverd in het source-project!) draait alles prima bij mij. Ik heb Acrobat 6.0 draaien. Ik heb 263 bestanden aangemaakt, en die zijn allemaal gethumbed!

Vreemd...

[ Voor 31% gewijzigd door PhysicsRules op 12-12-2006 21:55 ]

[eendje001]

PhysicsRules schreef op dinsdag 12 december 2006 @ 20:58:
Wat m opvalt is :

Visual Basic .NET:

 Dim ret As Integer
    ' Open the document
    ret = pdfDoc.Open(inputFile)

    If ret = False Then
        Throw New FileNotFoundException
    End If

Ik ben meer van de C#, maar daar zou dit niet compileren: een boolean met een int vergelijken. Misschien dat VB.Net dit impliciet cast, maar daar zou ik niet op vertrouwen.

Edit:
Geïntrigeerd door je probleem heb ik je project gedownload en uitgeprobeerd. Behalve dat het me wat moeite kostte om de juiste instellingen te maken (die heb je niet meegeleverd in het source-project!) draait alles prima bij mij. Ik heb Acrobat 6.0 draaien. Ik heb 263 bestanden aangemaakt, en die zijn allemaal gethumbed!

Vreemd...

Ok, hierdoor geinspireerd ben ik begonnen met het testen van andere versies van acrobat. Wonderbaarlijk genoeg bleek na het installeren van versie 6.0 het script inderdaad volledig te werken, zonder foutmeldingen, en liep alle 2000+ bestanden zonder problemen door. Hierna hetzelfde geprobeerd onder versie 8.0, en ook daar liep het geheel als een zonnetje.
Ik kan dus eigenlijk maar een enkele conclusie trekken, en dat is dat het ergens fout gaat in combinatie met acrobat 7.

In ieder geval werkt het nu. Woei!

Bovenstaande code ook maar even aangepast en ook meteen de suggestie van CodeIT geimplemeteerd, en nu hoeft hij ook niet meer door de recursive loop heen, en parsed hij alles netjes.
Het geheugengebruik is nu ook een stuk vriendelijker

Ik zal in ieder geval ook het project op codeproject updaten, dit maal met configfile...

Mijn dank aan iedereen die bijgadragen heeft aan het oplossen van dit probleem, mooie bijzaak is dat de code meteen ook een stukje opgeschoond is..

Voor het definitieve project kijk (inmiddels updated) even op Codeproject