Dit lijkt me een operatie die ofwel nutteloos is, ofwel problemen gaat geven.
Nutteloos als er geen software is die MSXML4 gebruikt, en problemen als er software is die het wel gebruikt.

Dus waarom zou je er dan aan beginnen?

Hmmm, ja, je hebt misschien wel gelijk.

Dat het verwijderen van MSXML 4 problemen oplevert wanneer essentiële software afhankelijk is van de aanwezigheid van MSXML 4, dat spreekt uiteraard vanzelf, en dat heb ik dan ook duidelijk aangegeven.

Maar dat het verwijderen van MSXML 4 nutteloos is wanneer er geen software (meer) aanwezig is die afhankelijk is van de aanwezigheid van MSXML 4, daar had ik eventjes niet bij stilgestaan.
Ook in de eerdere "MS ignores XML update issue" thread is op een gegeven moment aan de orde gesteld dat geen sprake kan zijn van misbruik van kwetsbaarheden in MSXML 4 zolang applicaties geen gebruik maken MSXML 4.

Is het zoals Anoniem van 10:53 uur aangaf wellicht wijs om MSXML 4 maar met rust te laten?
Of heeft iemand anders nog andere inzichten?

Hmm, ik weet niet of er misschien malware zou kunnen bestaan die MSXML 4 juist gebruikt om het systeem vervolgens kwetsbaar te kunnen maken voor een aanval. Of is dit misschien een beetje vergezocht?

Ik weet het niet.
Gezien de strekking van AdHd's reacties in de eerdere "MS ignores XML update issue" thread betreffend het niet automatisch via Windows Update updaten van MSXML 4.0 SP2 naar MSXML 4.0 SP3, vermoed ik dat het met misbruik van eventuele kwetsbaarheden gerelateerd aan MSXML 4 wel mee zal vallen.
Zie:
https://www.security.nl/posting/41791#posting359031
https://www.security.nl/posting/41791#posting359096

Niettemin vond ik het toch verstandig te melden dat MSXML 4 niet meer wordt ondersteund sinds 12 april 2014,
en voor wie MSXML 4 wil verwijderen aan te geven hoe dat te bewerkstelligen.

Of dat verwijderen van MSXML 4 raadzaam of zelfs maar nodig is, dat is dus echter maar de vraag.

Ik ben nog steeds benieuwd of het wellicht zo is als wat gisteren werd aangegeven door Anoniem van 10:53,
dat het waarschijnlijk wijs is om MSXML 4 maar met rust te laten,
of dat iemand anders andere inzichten heeft.

Bedankt Spiff voor het verwijzen naar de reacties van AdHd in de "MS ignores XML update issue" thread. Na deze reacties gelezen te hebben ben ik van gedachte veranderd en vermoed ik ook (zoals jij ook al schreef in je reactie van 09:58). dat het misbruik van eventuele kwetsbaarheden gerelateerd aan MSXML 4 wel mee zal vallen.


Overigens wel fijn dat je besloten hebt te melden dat MSXML 4 niet meer wordt ondersteund sinds 12 april 2014, dus nog bedankt daarvoor.

Het programma Secunia geeft aan dat MSXML 4 out too date is.

Het betreft het bestand MSXML4.dll in je system32 map in de 64bit versies WOW64 map

The Secunia score blijft op 99% staan ondanks alle pogingen om het via de software te verwijderen,
het bestand moet dan handmatig via de system32 map worden verwijderd wil je je secunia score weer op 100% (groen) krijgen,
of je kunt het natuurlijk ignoren,maar de vraag is idd of je systeem nu kwetsbaarder is of niet?

groeten
Lester

Voordat je het bestand verwijdert eerst even in een elevated cmd window "regsvr32 /u dllnaam" er tegen uitvoeren.

Microsoft raad zelf aan MSXML 3 of MSXML 6 (ingebakken vanaf Vista) te gebruiken. En alleen MSXML 4 te installeren indien een applicatie ervan expliciet afhankelijk is.

Als zowel 3 als 6 op een systeem naast elkaar aanwezig zijn verwijst de generieke MSXML namespace naar objecten uit versie 3. Dit is contra intuïtief. Wil je dus zeker zijn dat jouw applicatie alleen met versie 6 werkt zul je dus in je applicatie naar deze versie moeten linken. Hoe hebben ze het zo kunnen bedenken bij MS. Ja Ja Linux gebruiken zeker?

Dat klopt,
ik gaf dat aan in mijn startpost, onder "Verwijderen van MSXML 4":
https://www.security.nl/posting/396904/MSXML+4+end+of+support

Er zijn nog geen nieuwe kwetsbaarheden bekend in MSXML 4.0 met SP3 en de bijbehorende updates daarop.
Eventuele nieuw ontdekte kwetsbaarheden zullen echter niet meer gepatcht worden.
Betreffend misbruik van eventuele kwetsbaarheden geldt wat ik eerder aangaf:
https://www.security.nl/posting/396904#posting397041:

Zou je eerder naar aanleiding van dit eerdere topic
https://www.security.nl/posting/41791/MS+ignores+XML+update+issue
MSXML 4.0 SP2 nog niet hebben geupdate naar MSXML 4.0 SP3, dan is updaten met SP3 wel aan te raden.
Hoe dat te doen is in dat eerdere topic uitgebreid aangegeven.
Hier in het Nederlands: https://www.security.nl/posting/41791#posting357669

Of het vervolgens wijs is om
- ondanks het feit dat het sinds 12 april 2014 niet meer wordt ondersteund -
MSXML 4.0 met SP3 en de bijbehorende updates daarop maar met rust te laten,
omdat het verwijderen van MSXML 4 problemen oplevert wanneer essentiële software afhankelijk is van de aanwezigheid van MSXML 4,
en omdat het verwijderen van MSXML 4 nutteloos is wanneer er geen software (meer) aanwezig is die afhankelijk is van de aanwezigheid van MSXML 4, omdat er geen sprake kan zijn van misbruik van kwetsbaarheden in MSXML 4 zolang applicaties geen gebruik maken MSXML 4,
of dat iemand daar andere inzichten over heeft,
dat weet ik nog niet.

Ik hoop nog op reacties, ondanks de zomervakantie.
Zo nodig geef ik deze thread over een paar weken nog een zetje, wanneer mensen weer terug zijn van vakantie.

Regsvr32 /u <dll-naam> maakt de registratie van de betreffende dll ongedaan (unregisters the file).
Is dat noodzakelijk?
Kun je aangeven waarom dat noodzakelijk is?
Kun je zo mogelijk je bron of bronnen aangeven, zodat ik me kan inlezen hierover?
Ik vind wel dit, maar dat geeft me onvoldoende informatie over de noodzaak van Regsvr32 /u
http://support.microsoft.com/kb/249873
http://www.thewindowsclub.com/regsvr32-in-windows-explanation-usage-and-error-messages

En N.B.
Het zal niet één msxml4.dll betreffen, maar een cluster.
msxml4.dll, msxml4r.dll, msxml4r.dll.mui, en varianten daarvan met een voorvoegsel_ en _achtervoegsel,
het overgrote deel van die files in Windows\winsxs\
(Heb je geen MSXML 4 op je systeem, doe dan een zoekactie met msxml3.dll en/of msxml6.dll om te zien wat ik bedoel.)
Kan die hele cluster msxml4.dll files unregistered worden door middel van Regsvr32 /u msxml4.dll ?
Of moeten de msxml4r.dll en msxml4.dll.mui files nog apart unregistered worden?

Inderdaad.
Het vervelende is echter dat MSXML 4 op sommige systemen meegeïnstalleerd is met andere software.
Met software die al voorgeïnstalleerd stond bij aankoop, zoals bijvoorbeeld sommige spelletjes (heb je die crapware verwijderd, bleef MSXML 4 achter), of met software die je zelf geïnstalleerd hebt, zoals bijvoorbeeld sommige spelletjes of bepaalde printer-software.
Dat MSXML 4 aanwezig was door mee-installatie met crapware op een voorgeïnstalleerd systeem, of meegeïnstalleerd werd bij het zelf installeren van bepaalde software, daar zal vrijwel niemand zich van bewust zijn. Pas bij het zoeken naar MSXML 4 zie je dat het aanwezig is.

MSXML 4.0, SP2 en 3 zijn in fete niet kwetsbaar. De enige manier om code uit te voeren is door die code via een andere applicatie te 'parsen.' Dus A] heb je al controle nodig over het systeem en B] is dit erg opvallend voor een AV.
Updaten of verwijderen is niet nodig IMHO, als het al misbruikt kan worden is dat door lekken in andere software, niet door kwetsbaarheden in MSXML zelf. Dat geldt voor alle versies.


Ik breek even in:
Simpel gezegd, hierdoor weet Windows dat MSXML 4.0 niet meer op het systeem geïnstalleerd is. Het ontbreken van de bestanden kan een vreemde foutmelding geven als een applicatie MSXML 4.0 probeert aan te roepen, als deze op de correcte manier is verwijderd zal het systeem duidelijk aangeven dat MSXML 4.0 ontbreekt.
In het ergste geval zou het systeem BSOD's kunnen gaan vertonen, al acht ik die kans klein.

Alleen .dll's worden geregistreerd, dus niet .mui.


Ik zou het gewoon met rust laten, je weet nooit welke software het nodig heeft / gaat hebben en voor zover bekend is het op zich geen kwetsbare materie.

Ja, dat komt overeen met wat AdHd aangaf in de "MS ignores XML update issue" thread, denk ik.
https://www.security.nl/posting/41791#posting359031
https://www.security.nl/posting/41791#posting359096

Unregistering msxml4.ddl
Duidelijk, dank je.

En de msxml4r.ddl ?

Enkel wanneer iemand zeker zou weten dat de software die afhankelijk was van MSXML 4 is verwijderd (zoals ik aangaf, bijvoorbeeld bij aankoop reeds voorgeïnstalleerde spelletjes, of zelf geïnstalleerde software van een eerdere maar inmiddels afgedankte printer) dan zou MSXML 4 zonder nadelen verwijderd kunnen worden, mits dat correct gebeurt, dus met unregistering msxml4.ddl zoals ik inmiddels geleerd heb,
maar als de noodzaak tot het verwijderen van MSXML 4 ontbreekt, dan is dat verwijderen uiteraard onnodig.

Gezien het feit dat ik zelf geen MSXML 4 op mijn systemen heb, en met de computer van een vriendin die ik assisteer met haar computer geen onnodige risico's wil aangaan, zal ik MSXML 4.0 SP3 daarop negeren, ook al 'waarschuwt' haar Secunia PSI daarop dat MSXML 4 end of life is.


En geïnteresseerd geraakt door wat Eric-Jan H te A aanstipte betreffend unregistering .dll-files,
heb ik daar nog twee vragen over:
1.
Is unregistering van een .dll-file bij een andere gelegenheid eens werkelijk nodig,
moet Regsvr32 /u dan uitgevoerd worden vanuit de locatie van die betreffende dll-file,
of is het simpelweg uitvoeren van Regsvr32 /u <dll-naam> in een elevated cmd window voldoende (zonder navigatie naar de locatie van die betreffende dll-file)?
Uit de diverse bronnen die ik erover vond werd dat niet duidelijk.
2.
En moet eerst Regsvr32 /u <dll-naam> worden uitgevoerd en daarna de dll-file worden verwijderd,
of moet eerst de dll-file worden verwijderd en daarna Regsvr32 /u <dll-naam> worden uitgevoerd,
of maakt dat niet werkelijk uit?
Het wordt allebei genoemd, in verschillende bronnen.
Eén bron in géén bron, maar diverse bronnen die elk wat anders zeggen dat helpt ook niet erg.

Hmm, de vraag is "hoe veel wil je weten?"
CMD, msxml, .dll's, het Windows-register, het zijn allemaal niet de meest eenvoudige dingen.
Dus succes met m'n onderstaande post ;)


MSXML:
Inderdaad, je kunt MSXML 4.0 SP2 natuurlijk altijd updaten naar SP3 indien noodzakelijk, maar dat is op zich niet echt belangrijk. Niet vanuit security-oogpunt tenminste.


Hoe Windows werkt:
Graag gedaan, er speelt "iets" meer mee (famous last words), maar dat is er wat in dit geval belangrijk is. (dll bedoel je natuurlijk = Direct Link Library)

Het commando "regsrv32" (= Register Server 32(bit) = regsrv32.exe = geregistreerd systeem-bestand (zoals msxml4.dll) en daardoor uitvoerbaar als CMD-commando) heeft betrekking op het Windows-register en komt voort uit de manier waarop het OS input verwerkt (stiekem is dat eigenlijk nog gewoon DOS). Voor eindgebruikers is het niet handig om daar te veel mee te gaan prullen.., vandaar...


Goede vraag, nu krijg je de "iets" uitgebreidere reactie-versie:

Er wordt altijd gezocht naar basis-bestanden (zoals msxml4.dll). Ik ken geen uitzonderingen, al sluit dat niets helemaal uit natuurlijk.

Het kan verder geen kwaad om msxml4r.dll ook handmatig te verwijderen uit het register (via hetzelfde CMD-commando regsrv32 dus), maar msxml4r.dll is een zgn. resource-dll en bevat niet de soort (uitvoerbare PE-) code die de basis-dll bevat. Nogmaals, hoeveel wil je weten?

Overigens bestaat msxml4 uit ±200 bestanden, de meeste daarvan (allen?) zijn ook opgenomen in het register (ook die .mui dus), maar alléén msxml4.dll hoeft verwijderd te worden (fysiek + uit het register) om msxml4 onbruikbaar te maken.


NB: .mui = Multilingual User Interface, en zorgt er voor dat er maar één source-code nodig is voor een applicatie in meerdere talen. Ook deze bestanden zijn terug te vinden in het register (in tegenstelling tot wat ik, voor het gemak, eerder schreef) maar ze bevatten geen uitvoerbare code zoals een .dll (= vergelijkbaar met een .exe) en vormen dus géén risico.
Ook wordt er niet naar gezocht indien msxml4.dll ontbreekt. Vandaar...

NB-2: Nu zie ik net dat er ook een .ocx bij msxml4 zit, die zijn in theorie dan weer wél kwetsbaar (.ocx = OLE Control Extension, heeft te maken met ActiveX + COM/DCOM), maar ik ga er van uit (met >99% zekerheid, toch slecht eigenlijk) dat ook deze *.ocx onbruikbaar wordt bij het ontbreken van de basis-.dll.
Als je echt para bent kun je ocx-bestanden op exact dezelfde wijze verwijderen als dll's.


Dat lijkt me verstandig.
Als je het er niet zelf op hebt gezet, kun je het beter niet verwijderen !!!

Je kan het wel doen en dat levert hoogstwaarschijnlijk helemaal geen problemen op bij dagelijks gebruik.
Maar als je een keer iets (anders?!) tegenkomt en je neemt contact op met een helpdesk, kan het zijn dat hun oplossing niet meer werkt omdat die oplossing (indirect) afhankelijk is van msxml4. Lijkt misschien een beetje vergezocht, maar ik ben al gekkere dingen tegengekomen, al helemaal met JDK's en aan hardware-gerelateerde software!
Drivers zijn een ander verhaal en hebben nooit iets met msxml te maken voor zover ik weet.

Bij een verse OS-installatie zou ik het logischerwijs alléén installeren als dat nodig is.


Ja da's lastig allemaal, je zou eens op zoek kunnen gaan naar een studie? :p (Grapje, maar ik denk wel dat je het leuk zou vinden / iets op kan leveren).


Weer niet om in te breken, als Eric-Jan er iets anders van vindt horen we het vanzelf:
1] Het is alleen nodig als de uninstaller niet werkt / er niet is, en de software ook niet verwijderd kan worden via het configuratiescherm (= in feite hetzelfde). Dit is namelijk één van de dingen die "uninstall" hoort te doen.

Juist door een bestand te registreren zorg je er voor dat Windows dat bestand kan vinden / commando kan uitvoeren ongeacht vanuit welke locatie dat bestand / commando wordt aangeroepen (opnieuw, DOS!).
Het ZOU dus niet uit mogen maken vanuit welke directory je het commando uitvoert, noch waar het bestand fysiek is opgeslagen.
Dat het in dit geval ook nog in een systeem-directory staat laat ik nu even buiten beschouwing, dat hoeft namelijk niet altijd zo te zijn, wat dat betreft is je vraag 100% valide.
Voor de duidelijkheid: Als je het bestand fysiek verwijdert kan een vermelding in het register op zich geen kwaad t.a.v. security, de gevolgen hebben meer betrekking op stabiliteit en leesbaarheid van foutberichten.

2] In feite maakt de volgorde niets uit. Als je de bestanden ook via CMD (bijv. een script) verwijdert, is het handiger eerst de bestanden te verwijderen (Windows kan die dan nog makkelijk vinden dmv wildcards namelijk) en pas daarna de verwijzingen in het register op te ruimen. Zo doen uninstallers dat ook, als je het handmatig doet is er geen verschil.

Als een bestand nog geladen is in een actief proces, dien je eerst dat proces te stoppen natuurlijk. Het kan ook zijn dat je eerst de register-vermeldingen moet verwijderen, daarna opnieuw op moet starten en pas dan in staat bent om de bestanden van de schijf af te gooien. Vooral bij malware is dat vaak het geval, dat zal een mogelijke oorzaak zijn van de elkaar tegensprekende bronnen / werkwijzen, al komt er in het geval van malware vaak nog "iets" meer bij kijken (attrib, runonce, boot-commands etc.), maar dat laat ik nu even voor wat het is.


Algemeen mbt uninstallers:
In sommige situaties zou het wenselijk kunnen zijn dat er bepaalde verwijzingen uit het register worden gehaald en dat er bepaalde bestanden worden verwijderd die achterblijven na een -al dan niet succesvolle- "uninstall."

Ikzelf gebruik al jaren REVO om software te verwijderen (ipv uninstallers van de software zelf) en auslogics voor basis-onderhoud (ipv MS-tools) en heb daar nog nooit problemen mee / door gehad, maar feit blijft wel dat sommige zaken (zoals het register) niet gemaakt zijn om handmatig (als eindgebruiker) mee te gaan stoeien.
Het veelgebruikte argument uit MS-hoek dat het allemaal niet uitmaakt t.a.v. prestaties / stabiliteit is ook niet waar, het scheelt niet veel per entry / bestand, maar op een moment worden vele kleine druppels wel een enorme plas water, mede daarom loopt een verse installatie ook zo lekker snel.
CCleaner wordt vaak aangeraden en is ook prima, maar heeft hetzelfde probleem:


Voor mij werkt het 'handmatig' onderhouden van het register (+ systeem) prima en foutloos, maar als het een keer fout gaat zit je waarschijnlijk wel gelijk met allerlei vervelende problemen zoals onbegrijpelijke foutmeldingen, BSOD's en opstart-issues. Als je al niet 100% bekend bent met het verwijderen van entries wordt het oplossen van die problemen nog een hele uitdaging, zelfs met een back-up / systeemherstel. Dus vandaar de veelgenoemde adviezen om je register met rust te laten, verborgen bestanden niet weer te geven, etc.

Als het niet veel uitmaakt of een systeem werkbaar blijft zou ik juist zeggen dat het wel leerzaam kan zijn om je hier in te verdiepen. Maar natuurlijk NIET op het systeem van een vriendin! (Tenzij je van haar hulpvragen af wil natuurlijk :p)


Man man, wat een verhaal, wel leuk om eens wat info te kunnen delen (nerd-factor 9) hopelijk is het wat duidelijker zo, als er nog vragen zijn...

@ Anoniem 13:52 uur,

Geweldig,
hartelijk bedankt voor je uitvoerige informatie en uitleg.

Je vroeg, "hoeveel wil je weten?"
Nou, zoveel ongeveer, het was precies goed gedoseerd :-)
Wil ik later op een gegeven moment meer weten, dan heb ik op basis van wat je aanreikte een zeer goeie basis om verder te zoeken (en/of verder te vragen). Maar voorlopig ben ik precies voldaan, nogmaals bedankt.

En haha, nee, nee, uiteraard ga ik niet experimenteren op het systeem van die vriendin. Ik vind haar en haar hulpvragen veel te leuk, daar hoef ik niet vanaf, van allebei niet.

En leuk dat je het leuk vond om info te kunnen delen met nerd-factor 9.
Ik hoop dat het je niet spijt dat ik al voldaan ben ;-)

Dag,
en nogmaals bedankt.

Mooi!
Graag gedaan, meestal kom ik mensen tegen die een "nu-meteen-oplossing" willen in plaats van te weten wat de oorzaak van een probleem is, dus ik vond het leuk om te doen.
Plus, het is vakantietijd, niemand met problemen te bekennen hier... ;)

Jij ook bedankt, ik ervaar het als een groot compliment dat je mijn reactie hebt gelezen en begrepen, dat betekent dat het informatief en begrijpelijk was, en dat vind ik niet makkelijk bij materie als deze, zeker ook omdat ik geen flauw idee heb van jouw kennis van het OS.

Hahahaha, was maar een grapje hoor, ik vind het -over het algemeen- ook leuk om mensen te kunnen helpen, maar nogmaals, er zijn best mogelijkheden om op de bus te stappen die ICT heet, ik weet niet waar precies je interesse's liggen maar daar kun je echt iets (leuks/nuttigs/wel-of-niet-tegen-betaling) mee doen.
Mij is het ook gelukt :p


Bedankt voor je feedback!!!

Eric-Jan H te A (Chrome x64 heeft het wat moeilijk met het inloggen op Security.nl)


tJa dat moge zo zijn om dit moment, maar de support vervalt. En dat betekent dat je van Microsoft
niks meer hoeft te verwachten. Ook geen berichtje als er wel problemen opduiken.

Ik zou juist zeggen: "Better be save then sorry". En mocht versie 4 plotseling toch ergens voor nodig zijn, kun je het op dat moment altijd weer installeren.

Verder zijn geloof ik vragen aan mij gericht al vriendelijk door anderen beantwoord. Dank daarvoor.

Eentje is verkeerd beantwoord: msxml4r.dll heeft geen unregister sectie. Regsvr32 /u geeft dat keurig aan. No harm done

P.S.
Uiteraard, dll, niet ddl.
Dankjewel voor het wijzen op die fout.
Het was een typo, die ik stomheidshalve nog tweemaal maakte of overnam in diezelfde tekst.
Foei toch, Spiff!

Ten slotte -
Mijn start-post van 29-07-2014, die heb ik zonet aangevuld en bijgesteld naar aanleiding van hetgeen aan informatie naar voren kwam in het vervolg van deze thread.
Hartelijk dank aan alle bijdragers aan deze thread.

Goed bezig!


Hahaha, ja dat zag ik -heel begrijpelijk trouwens, is wel handig kopiëren met BB natuurlijk!- en gelukkig was de strekking van je verhaal duidelijk. De reden dat ik er een opmerking over plaatste is dat de DDL-extensie ook regelmatig voorkomt, als zijnde Data Definition Language (SQL). Niet dat het in dit geval verwarrend was, maar toch...


Maar als we dan toch gaan beginnen, deze moest ik wél 2x lezen voor ik het doorhad:

Huh? Wow, Ad fontes! e/o Ad fundum!
(Sorry, voor mij is het óók warm hoor! XD)

Alvast een prettig weekend!

Als ik zou gaan klooien met Microsoft MSXML 4 (Microsoft XML Core Services 4) zou ik eerst een backup maken en
een register kopie.


Ik vind het vreemd dat Microsoft geen de-installatie/controle programma geeft voor verwijdering overbodige verouderde bestanden.
Als controle gebruik Belarc Advisor Computer en Microsoft Baseline Security Analyzer 2.2
Maar veel wijzer wordt ik hier door niet.

MSXML 4.0 SP3 Parser (KB2721691)
no verification data KB2721691 on 24-8-2012 (details...)
MSXML 4.0 SP3 Parser (KB2758694)
no verification data KB2758694 on 9-1-2013 (details...)
MSXML4SP2
no verification data KB954430 on 14-3-2010 (details...)
no verification data KB973688 on 14-3-2010 (details...)
MSXML4SP3
no verification data Q2721691 (details...)
no verification data Q2758694 (details...)

Tja, die n was ook weer een typo.
Uiteraard bedoelde ik "één bron is géén bron".
Wat ik in plaats daarvan schreef was uiteraard nogal een raadseltekst, vooral ook nog eens door de koppeling met het tweede zinsdeel dat het met z'n 'bronnenvermelding' nog erger maakte.
Ach, ach, ach, en dat terwijl ik altijd zo probeer op te letten :-)
Ja, het zal de warmte zijn. En teveel dingen op een dag willen doen.

Jij ook een prettig weekend toegewenst
en de andere lezers en bijdragers uiteraard ook.

Wat betreft het de-installeren verschillen we van mening dan, ik zie veel meer potentiele problemen t.a.v. stabiliteit en functionaliteit dan t.a.v. security. Eindgebruikers raad ik aan om het alleen te verwijderen als ze het er zelf op hebben gezet.

Jij bedankt voor je bijdrage, en wat betreft regsvr32 /u msxml4r.dll -> foutje bedankt -> ik zal het voortaan ook even daadwerkelijk zelf testen voor ik reageer ;)


Back-ups maken is even belangrijk als logisch lijkt me, en dat mag best even benadrukt worden. Al kun je op die manier wel bezig blijven met waarschuwen natuurlijk...

MS heeft een enorme toolbox voor systeem-onderhoud, MS-update (WSUS) als belangrijkste, maar ik heb zelf de voorkeur voor 3rd-party software.
Als het gaat om software-updates zou ik Secunia aanraden, als het gaat om het verwijderen van temp-files is er bijv. CCleaner, en als je wat dieper wil graven zijn er tal van tools en ontwikkelaars die (gratis) oplossingen bieden, ik noemde auslogics al. REVO kun je gebruiken om (bijv.) msxml4 volledig en correct (dit heb ik net wél even zelf getest) te verwijderen zonder cmd te hoeven gebruiken.
Let wel altijd goed op als je op zoek gaat naar software, er is meer rommel / spyware / adware / scareware dan goede software te vinden... (VirusTotal is al een fijne indicatie wat dat betreft.)

Met alle respect, maar Belarc (geinig programma trouwens, bedankt voor de tip!) en MS-BSA zijn niet bedoeld om het systeem te onderhouden maar als indicator bij het opsporen van mogelijke, security-gerelateerde problemen.
(En dat is msxml4 niet.)


Geeft allemaal niets, sorry, ik bedoel het niet anders dan goed!

Adieu!

Ah, bedankt.
Ik heb de vermelding van het uitvoeren van regsvr32 /u msxml4.dll inmiddels verwijderd uit mijn start-bericht, waaraan ik het eerder had toegevoegd.

En betreffend de typo's,
Maar natuurlijk.
We bedoelen het hier allemaal alleen maar goed.
Dat er af en toe een typo of een ander foutje wordt gemist en dat daar dan een opmerking of grapje over gemaakt wordt, dat hoort er evengoed bij, gelukkig :-)