Windows 10 lijkt drivers van derde partijen in aparte map te gaan plaatsen

Het lijkt er op dat Microsoft bij de komst van de 21H2-update van Windows 10, drivers van derde partijen naar een speciale map zal verplaatsen. Die komen dan in hun eigen oemdrivers-map buiten de system32-map.

De functie heeft de naam Writeable_DriverStore en moet geactiveerd worden bij het voor het eerst booten van een nieuwe Windows 10-versie. Daarna verplaatst het OS alle drivers van derde partijen naar de map 'oemdrivers', die zich direct onder C:\Windows\ bevindt. Dat ontdekte Albacore, die zich richt op het ontdekken van nieuwe functies in met name Windows. Zo ontdekte hij deze week ook een tot nu toe onbekende easter egg in Windows 95.

De komende Windows 10-driverfunctie verifieerde hij door de constatering dat het OS na de eerste keer booten in een virtuele machine, drivers in de oemdrivers-map geïsoleerd had. De wijziging moet vooral de beveiliging van Windows 10 verbeteren. Tot nu toe slaat Windows drivers, zowel eigen drivers als die van derde partijen, op in de DriverStore die zich onder C:\Windows\System32 bevindt.

De wijziging zit in Windows 10 Insider Preview Build 21343, die Microsoft vorige week vrijgaf. Functies daaruit kunnen eind dit jaar verschijnen als Windows 21H2, een omvangrijke update die Microsoft op de planning heeft staan.

Windows 10 oemdrivers

Door Olaf van Miltenburg

Nieuwscoördinator

31-03-2021 • 10:03

77

Submitter: TheVivaldi

Reacties (77)

77
74
41
4
0
27
Wijzig sortering
Wat maakt het concreet uit in welke map deze drivers staan?

Wat is het verschil tussen:
C:\Windows\System32
C:\Windows\OEMDRIVERS
Het zal met isolatie te maken hebben en ik kan MS geen ongelijk geven.
De afgelopen 10 jaar hebben ze security wise stappen gezet door systeemprocessen te isoleren per gebruikerssessie en het gebruik van systeemfolders van hun besturingssysteem door 3rd party vendoren in te dammen.

Dit is een opmaat naar isolatie op driver niveau en het indammen van het gebruik van bestanden die zich in C:\Windows\System32 bevinden . In een wereld waarin het dreigingsniveau dermate hoog is en alle middelen worden aangewend om een kwetsbaarheid uit te buiten is het onvermijdelijk dat MS hun besturingssysteem langs alle mogelijke middelen hiertegen zal beschermen.
Precies dit. Het is een opmaat naar de systeem folders verder in te dammen zodat alleen zeer vertrouwde processen zoals de trusted installer hier standaard nog iets mee kunnen. Alle rest zal naar satteliet-folders zoals de nieuwe Windows\oemdrivers verkast worden, welke met een lager toegangsniveau kunnen werken.

Malware heeft op die manier minder makkelijk kans om zich in te vreten in de System32 folder. Het neemt in dit geval natuurlijk ook wat risico's weg omtrent niet malafide, maar gewoon slecht geschreven drivers.

Bijv. het risico dat er een name-collision optreedt en zo'n driver een Windows-eigen file overschrijft. Of van die heel slecht geschreven 'installers' voor 32-bit drivers die keihard een copy doen naar de System32 folder, wat op een 64-bit Windows totaal fout gaat. System32 bevat nl. de 64-bit omgeving en SysWow64 de 32-bit omgeving. (Wat op zich ook weer zo'n leuk geval was van backwards compatibility met slecht geschreven software pogen te handhaven.)

[Reactie gewijzigd door R4gnax op 22 juli 2024 15:20]

Wat maakt het concreet uit in welke map deze drivers staan?

Wat is het verschil tussen:
C:\Windows\System32
C:\Windows\OEMDRIVERS
Concreet weinig. Het is meer dat het ruimte biedt voor vervolgstappen.
Je zet alle stukjes die kunnen veranderen bij elkaar en dan kun je de rest van je installatie bevriezen op z'n minst makkelijk controleren op ongewenste veranderingen.

In de Docker wereld is het heel populair om met 1 read-only image te werken met daarin al je software en je configuratie en data in losse directories te zetten die je buiten dat image houdt. Zo weet je zeker dat je basis niet kan veranderen en kun je alle energier richten op het goed beveiligen van de paar files die niet in het image zitten.
Inderdaad toch handig, hoef je niet heel de system32 map door te spitten, mocht je een driver zoeken
Het kan voordelen bieden als je een backup wilt maken van de custom drivers, die dus niet standaard bij windows zitten.
Toegang tot mappen, samenwerking met windows dll's en drivers die in diezelfde system32 map staan.
probleem treed alleen op als een leverancier dus geen aanpassing maakt in waar (sub)onderdelen te vinden zijn in hun eigen drivers. kan dus prima voorkomen dat een driver voor een oud device niet meer werkt en niet meer gaat werken omdat er geen nieuwe driver voor uitkomt die rekening houdt met deze wijziging.
Ik vraag me af of dat zo gaat werken. Als oude software naar “my documents “ probeert te schrijven wordt dat automatisch omgeleid naar de juiste locatie in het huidige profiel. Bij drivers kunnen ze natuurlijk hetzelfde doen. Natuurlijk kan het nog steeds mis gaan maar ik denk dat juist oude drivers goed geïsoleerd gaan worden (ook omdat MS die ongetwijfeld als testcases mee neemt)
ik begrijp wat je zegt, maar die "my documents" map als voorbeeld heeft een windows variabele welke gebruikt kan worden, een beetje driver-fabrikant gebruikt dan ook de system32 variabele voor zijn/haar drivers als in die map nog andere afhankelijkheden staan. zelf ben ik ook benieuwd hoe MS het voor elkaar gaat krijgen dat die drivers nog steeds blijven werken, ofdat het stuk gaat en MS het onder het stukje "Niet meer supported" schuift.
Dat was precies mijn punt ;)
Blijkbaar zit er iets in het systeem die dat soort hard coded calls onderschept en daar de systeem variabele tussen steekt. Mijn vermoeden is dat ze dat ook met calls naar system32 gaan doen. Immers als alle drivers daar buiten komen kan elke schrijf actie re-routed worden
Orde en netheid :)
De System32 map is door de jaren heen bijna een vuilbak geworden voor alles.
Het lijkt mij logische dat MS, op termijn, de System32 gaat afsluiten voor alle niet-windows bestanden.
In een volgende stap verwacht ik dat ze ook een OEMDLL map gaan introduceren.
Microsoft kan in principe super strakke integriteitsregels instellen op hun eigen drivers in hun eigen mapje. En als de driver dan iets overtreedt dan kunnen ze dat zelf oplossen. Maar voor drivers die ze niet zelf maken kunnen ze dat niet garanderen. Voor sommige apparaat soorten kan je zelfs nog XP drivers inladen (op 32 bits Windows 10). Die zullen vast niet altijd aan de moderne inzichten van beveiliging voldoen.
Vooral bij laptops die vendorspecifieke componenten met eigen drivers gebruiken kan het verdomd handig zijn om die custom drivers apart te kunnen backuppen.
Vele jaren geleden deed ik nog weekendwerk in een pc winkel en gebruikten we een speciale tool om alle drivers te backuppen van pc's, want als je die dingen herinstalleerde was de enige manier om de juiste drivers te krijgen het herinstalleren van de volledige system image voor dat model laptop.
Gezien de functie writable driverstore heet, zal Microsoft de system32 map wel alleen door system willen laten beschrijven. Dan krijg je minder rotzooi in die map, wat reset/herstel makkelijker maakt en daarnaast maakt dat alles een stuk veiliger.
Nu kan allerlei malware via het admin account daar nog in schrijven.
Liever 10 van dit soort nieuws artikelen dan het zoveelste over een icoontje dat iets van stijl verandert.
Anoniem: 24916 31 maart 2021 10:55
Lijkt mij ook handig om die map OEMDRIVERS te verwijderen als je een image maakt die je op andere PCs/laptops terug wilt zetten.
In 1 klap geen onnodige of foute drivers meer op het nieuwe systeem en alleen nog even de verborgen niet aanwezige hardware in het hardware overzicht verwijderen.

Zo kan een image weer een stukje kleiner en stabieler worden als je die op verschillende hardware configuraties wilt plaatsen lijkt mij.
Hier kon je al de generalize image (sysprep) functie voor gebruiken, dus ik zou nooit handmatig folders weggooien in je image.

Met de "Microsoft-Windows-PnpSysprep/*" settings kun je dan je drivers tijdens installatie correct laten opruimen bijvoorbeeld of juist laten bestaan voor niet detecteerbare hardware.

Je kunt dat waarschijnlijk beter niet handmatig doen.
Anoniem: 24916 @EraYaN1 april 2021 00:28
Ik heb serieus nog nooit een probleem gehad of gezien met mijn manier en die werkt super.
Nu dus nog iets beter omdat de drivers in een aparte folder komen te staan en dus super simpel voor het maken van een image even te verwijderen zijn.

Mijn image is volledig up-to-date, bepaalde store apps geïnstalleerd en alles up-to-date dat met sysprep niet mag, Office 2019 geïnstalleerd, maar niet geactiveerd, 100den aanpassingen en optimalisaties, enz...

Image op een nieuwe PC, drivers bijwerken (meestal is via Windows Update voldoende), verborgen niet aanwezige hardware verwijderen en eventueel de drivers, klaar... Binnen een half uurtje een PC/laptop volledig klaar en geen uren installeren en bijwerken meer.
Dat zal wel werken voor 1 install maar als jij een vloot laptops moet reimagen is dat natuurlijk niet de manier. Dan wil je gewoon een golden sysprepped image (dus zonder user info etc) en een unattended.xml hebben en waarschijnlijk een MDM.
Anoniem: 24916 @EraYaN1 april 2021 12:38
Ik heb nog nooit ook maar 1 probleem gehad.
En de user aanmaken met een Microsoft account doe je natuurlijk niet in de image, maar voor iedere laptop/PC apart.
Ook de PC naam even aanpassen.
Hopelijk is dit een maatregel die er eindelijk voor zorgt dat Windows Update niet meer automatisch de manufacturer customized Intel VGA driver op mijn ThinkPad overschrijft. momenteel moet ik een GPO instellen om geen driverupdates meer via Windows Update binnen te halen, omdat anders ineens een generieke Intel VGA driver geïnstalleerd wordt en in een keer de helderheid van het scherm niet meer te bedienen is.
Hier probeert Windows Update ook telkens een driver voor mijn HP printer binnen te halen. Terwijl de HP driver nieuwer is dan die van Microsoft. Waardoor Windows Update een foutmelding geeft dat de driver niet geïnstalleerd kan worden.
"Het is mogelijk dat een huidig stuurprogramma op uw pc beter is dan het stuurprogramma dat we proberen te installeren. We blijven proberen de installatie uit te voeren."

[Reactie gewijzigd door slaay op 22 juli 2024 15:20]

Als je HP Smart uit de store download, zou die het beheer van de HP printer drivers over moeten nemen.
Maar niemand gebruikt de store. Althans, elke keer als ik hier over de store begin, krijg ik tig reacties dat zowel tweakers als 'Henk en Ingrid' de store niet gebruiken.
Je 'gebruikt' de store meer dan je denkt want alle updates voor ingebouwde apps werken via die store (kijk maar onder updates). Ook worden automatisch programma's geïnstalleerd als je bepaalde hardware aansluit. Een voorbeeld is Razer Synapse wanneer je een razer muis aansluit. Bloatware on-demand, een nieuwe mijlpaal voor Windows..

Dus je gebruikt deze store echt wel, of je het nu wil of niet :+
Wat niet de fout is van Microsoft volgens mij. Het is aan HP om die nieuwe driver "aan te melden" bij Microsoft zodat die dan gebruikt wordt in Windows Update.
Dit kan je blokkeren: https://www.laptopmag.com...r-downloads-on-windows-10

Zo was ik ook altijd na elke update mijn Realtek driver kwijt. Leuk is dat Windows bij de optie weergeeft "your device might not work as expected" terwijl de "recommended" optie er juist voor zorgt dat mijn geluid steeds niet werkt.
Ha ha.... echte "Windows-slimheid". Dat is ongeveer dezelfde snuggerheid als de melding "No keyboard detected. Press F1 to continue". :P
Dat is een BIOS melding... Vrij weinig met Windows of Microsoft te maken. :/
http://alphahole.net/?p=1011

[Reactie gewijzigd door N97 op 22 juli 2024 15:20]

Dat zou die al sinds versie 2004 niet meer moeten doen. Dan zouden ze in de "Optionele Updates" lijst moeten belanden.
En dan besluit ie dat om de ene of andere reden bij de Intel VGA driver alsnog te doen |:(
Windows heeft een feature om updates van drivers te voorkomen, je kunt daarvoor na de update in device manager op de knop "revert driver" o.i.d. klikken. Hij installeert dan de vorige driver en onthoudt om de nieuwe driver niet nogs eens te installeren. Die feature zit er al een tijd in, alhoewel sommige manufacturers hem te lijken verstoren met hun eigen driverupdateprogramma's.

Wel vaag dat de manufacturer dermate aan de hardware heeft geknutseld dat de brightness control van Intel zelf niet meer werkt. Er zijn tig securitylekken gevonden in de Intel-GPU-drivers, dus ik hoop wel dat je regelmatig security-updates van Lenovo krijgt als die van Intel niet op je laptop werken
Driver updates in de windows store staan toch al in de optionele updated die je handmatig moet aanvinken, althans bij mij wel sinds 20H2 (misschien al wel langer).
Wordt spannend qua installatie; ik kan mij erg goed voorstellen dat heel veel driver-bouwers de aanwezigheid van de drivers in de system32 map als vanzelfsprekend hebben opgenomen in de installatie en verwijzingen binnen de applicaties.

Ik verwacht vooral bij oudere drivers veel problemen, hopelijk gaat Microsoft hier een mooi jasje omheen bouwen zodat de verouderde verwijzingen automatisch worden doorverwezen (symbolische links?)
[edit]
Je had zelf al de oplossing met symlinks :-)
De locatie zou niet uit moeten maken. System32 is toch een virtuele map, niets is wat het lijkt daar. Microsoft kan het waarschijnlijk goed opvangen met een backwards compatibility mode voor drivers die zich niet aan de richtlijnen gehouden hebben.
Als je %windir%\System32\driverxxx.ini aanroept dat een not found krijgt die automatisch %windir%\oemdrivers\driverxxx.ini probeert. Dan goed aankondigen dat dit naar x tijd (zeg 36maanden) deze feature uitgezet gaan worden. Om bedrijven te forceren hier toch iets mee te gaan doen.

Deze aanpassing kan wel problemen veroorzaken met applicaties die hardcoden C:/Windows/system32/driverxxx.ini. Helaas zijn er nog steeds applicaties die dit doen. Zeker van wat minder ervaren ontwikkelaars. Heb hier zelf problemen mee gehad toen ik mijn Windows naar Z: had veranderd omdat het kon. Dat ik regelmatig errors kreeg of applicaties die gewoon ontplofte omdat ze C:/Windows/xxxx niet konden vinden. Er is een reden dat Microsoft variabelen heeft voor bepaalde folders.
Ja, inderdaad, ik heb dat ook eens gemerkt met Windows op een andere drive letter.
Op zich wel goed voor security: veel malware heeft ook paden hardcoded.
Maar af en toe werkt een normale applicatie ook niet goed.
Microsoft kan beter zijn eigen drivers verplaatsen dan die van anderen, dan krijg je niet de problemen van programma's die hun drivers niet meer kunnen vinden.
Voor programma's die hun data in de programmamap willen opslaan is er al de map VirtualStore. Misschien doen ze nu iets vergelijkbaars.
3e partijen? Wie bedoelen ze dan?
Niet door Microsoft zelf aangeboden drivers.
Vallen CPU / chipset drivers onder aangeboden door Microsoft. Of zijn dat externe? Want de drivers zijn vaak toch van AMD / Intel.
In principe alles wat je zelf moet installeren geldt als OEM. Dus als je iets downloadt en het komt niet standaard met Windows of Windows update.
Ik krijg mijn chipset updates ook via Windows update. Vaak zijn dat niet de nieuwste drivers vaak lopen die een of twee versies achter. Zodat Microsoft zeker weet niet alles kapot gaat bij het updaten van de driver.

Valt die dan onder oemdrivers of niet? Het is nu natuurlijk nog gissen. Er zal binnenkort een veel te lange post van Microsoft komen waar ze alles in uitleggen.

Als ik morgen een OS zou ontwikkelen zou ik zelf zeggen. C:/Windows/drivers/Chipset/driverxxx.ini of /drivers/Intel/driverxxx.ini. Zodat als je gaat kijken in je driver folder je ook kunt zien welke driver waarbij hoort. Niet dat veel mensen hun drivers zullen bekijken maar als poweruser en je hebt een driver die je wilt uploaden voor een bugreport is het soms wel lastig om de juiste te vinden.
Als Windows ze zelf installeert, zij het bij een verse installatie, zij het door een update, dan zullen ze in system32 blijven staan. Als je zelf op de site van de fabrikant gaat downloaden en deze handmatig installeert zullen ze in deze nieuwe folder terechtkomen.
Dat maakt het juist vervelend, dan kan je dus twee keer een driver hebben van een bepaald onderdeel op twee plekken met alle twee een andere versie.

Zeg je Chipset via Windows update installeert versie 10.0. Vervolgens ga je zelf een rondje drivers updaten. Krijg je 10.1 in je /oemdriver/. Dit kan toch juist voor problemen zorgen? Want Windows ziet zowel een valid driver in system32 en in de oemdriver. Zal voor Windows zelf hier (hoog waarschijnlijk) netjes om mee gaan. Door bijvoorbeeld eerst te naar de versie maar niet elke applicatie zal dat doen. Omdat ze %windir%/system32 aanroepen.

Is het niet tijd wat Windows naar een aanspreekbaar driver store gaat dat je gewoon %driver% hebt. Dat hier al je drivers locaties ingezet worden. En dat als ik morgen een driver van het internet pluk en deze zelf installeer dan gewoon in de driver store de versie verander en de locatie. Of dit nu first party is of gevalideerde third party of niet gevalideerde third party drivers zijn.

Als dit makkelijk te bekijken is, kan zelf een gewone gebruiker hier iets van snappen als zij bijvoorbeeld tech suppport bellen want iets werkt niet. Als je nu een specifiek probleem hebt en het kan een driver error zijn. Zou het voor tech support makkelijk moeten zijn om haar gebruikers hierna toe te krijgen.

Dat in die store staat bijvoorbeeld
Name | Version | Company | Validated | Installed via | Location | Get Driver
chipset.inf | 10.1 | Intel | True (met certificaat) | Windows update | /sys32/driverx123.inf | Click save as


Ik zie niet welk probleem Microsoft op wilt lossen.
Wat jij beschrijft is net het concept waar men van af stapt, men wil net een splitsing bekomen tussen drivers die door MS gevalideerd en verdeeld worrden en drivers die via een derde partij worden aangeleverd.
Ik zie niet welk probleem Microsoft op wilt lossen.
Dat staat in het artikel:
De wijziging moet vooral de beveiliging van Windows 10 verbeteren.
Ik kan me voorstellen dat je je eigen drivers beter kunt afschermen als je weet dat een gebruiker nooit iets kan/mag schrijven in die driver folders, want de drivers die een gebruiker installeert komen altijd een andere lokatie.
Dat maakt het wellicht ook makkelijker om de driver lokatie onbereikbaar te maken voor malware.

Dat zal uiteraard niet zo simpel zijn als ik het nu voorstel, maar de focus is dus niet op de gebruiker in system32 wil kunnen rommelen.
ik zou zeggen alle drivers die niet samen werken met de Windows Update feature? dus je nvidia/amd drivers niet maar de rare USB to com port dongels die niet standaard door windows ondersteund worden.
Als je een clean install deed werd er toch altijd al een aparte map gemaakt als je nieuwe drivers installeerde?
Alles wat niet van Microsoft zelf is
Jawel snap ik, maar dan bedoelen ze Intel, Realtek, AMD, Nvidia enz enz..
Een OEM is een fabrikant van volledige computers, zoals Dell of Toshiba. Dus ik denk dat alle drivers die meegeleverd gaan worden bij install in een aparte map komen. Ik durf je nog niet te zeggen of het ook gaat gelden voor hardware drivers van bijvoorbeeld Nvidia die via Microsoft update binnenkomen.
Een OEM is een fabrikant van volledige computers
Hoewel je geen ongelijk hebt is dat niet wat hier bedoelt lijkt te worden en lijkt het simpelweg te gaan om alle drivers van derde partijen. In andere woorden, drivers die microsoft zelf niet levert/maakt. Iets anders zou in deze context ook apart zijn aangezien er dan sprake is van een nogal arbitraire scheiding.

[Reactie gewijzigd door Creesch op 22 juli 2024 15:20]

Eerste partij: Microsoft, tweede de gebruiker en derde: alle anderen. NVidia, Amd, etc.
Logitech webcam, HP printer etcetera.
eeehhh, als je niet onder Microsoft valt dan ben je een derde partij?
Alle vendors die losse drivers uitgeven. De drivers die Windows update komen en/of automatisch binnengehaald worden hebben moeten we kijken wat ze ermee gaan doen maar ik verwacht dat die niet als 3rd party aangemerkt worden.
Vraag me af wat voor impact dit gaat hebben op het hele cheating wereldje.
Veel cheats gebruiken namelijk drivers om anticheats te omzeilen en om de memory van de desbetreffende game te lezen.
Vaak gaat het om unsigned drivers dus je neemt als gebruiker sowieso een enorm risico door die troep te draaien, maar ik kan mij voorstellen dat een anticheat niet zo maar drivers mag gaan inspecteren.
Om eerlijk te zijn verbaast het me lichtelijk dat diet niet al zo werkt. Je zou toch verwachten dat je spul van derden isoleert van je eigen bestanden. Maar je bent nooit te oud om te leren, MS incluis... :-)
Een nieuwe easter-egg in Windows 95? Het is weer bijna pasen, dat snap ik wel. Maar wie heeft er nog toegang tot Windows 95? Wie gebruikt dat nog?
Ik kwam op mijn werkplek nog een doosje floppy's met Windows 95 tegen..... en enkele collega's, die geen idee hadden, wat het was (zowel floppy's als Windows 95) ;-)

[Reactie gewijzigd door EdwinH. op 22 juli 2024 15:20]

In het begin van de virtualisatie met VMware heb ik wel een Windows 98 OSR2 (uit 1999) installatie gemaakt en die moet ik nog ergens hebben, ik zal die weer eens opstarten, zien wat er nog werkt.

Maar windows 95 dat is nog 4 jaar ouder, al moet ik zeggen dat ik aan het begin van deze eeuw bij een club werkte die bewust W95 draaide en geen W98. Al weet ik niet meer waarom.
als ik het me goed herinner dan was 98 buggy as hell.. pas bij 98 Second edition begon het weer een beetje te werken
Ik heb problemen met Windows 10 20H2, zodra ik die upgrade installeert worden mijn interne 3.5" traditionele harde schijven niet meer herkend in venster "Deze Computer? Terwijl mijn 2 M.2 NVME 980 Pro 1TB en 970 EVO 1TB wel zichtbaar is en mijn externe harde schijven. Zelfs mijn SSD Samsung 840 EVO wordt intern niet meer herkend.

Hopelijk is bij deze nieuwe 21H2 deze problemen hiermee opgelost. Zodra ik Windows 10 2004 opzet werkt alles naar behoren en heb ik alle schijven weer tot mijn beschikking

[Reactie gewijzigd door Van der Berg op 22 juli 2024 15:20]

Totaal off-topic, maar het klinkt alsof je SATA controller dan niet meer werkt onder 20H2.
Waarom communiceert MS wijzigingen als deze niet? Als je drivers maakt lijkt mij het toch handige informatie? Wat als je moet debuggen?
Het is in een preview voor tegen eind dit jaar, nog ff tijd voor hun om de nodige communicaties te doen?
Naar de driver leveranciers zou het wel eens wel zijn doorgegeven, mogelijk tussen nog veel meer zaken.

Aan de andere kant: als het goed is worden dergelijke zaken al zo'n 25 jaar ook bij msWindows niet op harde paden geïnstalleerd maar op basis van systeem variabelen. Daarbij vraag ik mij af welke systeem variabele ze hier gebruikt hebben.

Daarmee: het zou niet zo mogen zijn dat ze een geïnstalleerde installatie daar in veranderen. Als een driver nu al in de oude-standaard-lokatie staat, dan zou ze daar moeten blijven staan.

[Reactie gewijzigd door beerse op 22 juli 2024 15:20]

Ga er maar van uit dat dit soort wijzigingen ook netjes doorgegeven worden aan de grote OEM leveranciers, zou me zelfs niet verbazen als dit in samenwerking gedaan is met enkele.

Op dit item kan niet meer gereageerd worden.