Windows-update sloopt Office-integratie van derden via OLE-automatisering

Microsoft erkent dat een recente Windows 11-update voor versies 25H2 en 24H2 de Object Linking and Embedding-functie (OLE) in combinatie met Office-programma's kan slopen. Het bedrijf werkt aan een oplossing, maar benadrukt dat dit eigenlijk de verantwoordelijkheid van de externe softwaremakers is.

OLE is een Microsoft-functie waarmee programma's gegevens en functies kunnen uitwisselen. Dat is bijvoorbeeld nodig voor het gebruik van verschillende Office-toepassingen in één bestand of het gebruik van Office-software zoals Excel vanuit gespecialiseerde software voor bijvoorbeeld accountants of tandartsen. Microsoft noemt als voorbeeld CCH Engagement, Workpaper Manager en software voor tandartsen zoals Dentrix en Softdent.

Na een recente Windows 11-update kunnen bepaalde programma's die OLE-automatisering gebruiken mogelijk geen Office-bestanden meer openen. Er verschijnt in sommige gevallen ook geen foutmelding. Microsoft werkt aan een oplossing, die in een 'toekomstige Windows-update' moet komen. Er is ook een workaround: de bestanden direct openen in plaats van via de getroffen software.

Microsoft ontkent verantwoordelijkheid

Microsoft zegt daarbij: "De vermelde producten worden door externe bedrijven gemaakt die onafhankelijk van Microsoft zijn. We geven geen garanties over de prestaties of betrouwbaarheid van deze producten."

Daarmee impliceert het bedrijf dat het compatibel houden van de zakelijke software met Windows 11 de verantwoordelijkheid van de softwareaanbieders is. Volgens The Register zijn de applicaties echter volledig afhankelijk van de OLE-functionaliteit, die Microsoft sinds de jaren '90 ondersteunt. Mogelijk hadden ontwikkelaars geen kans om zich voor te bereiden op de plotselinge onderbreking van die functie.

Reacties (52)

[sjoerdadlp]

Bekende programma's zoals....? Ik mis heel wat context hier.

[useruser]

Vooral ouwe meuk. In mijn ervaring is software met ole koppelingen in Excel minimaal 20 jaar oud en hangt het van ellende aan elkaar.

Nu komen er vast meerdere mensen mij vertellen dat ik het helemaal mis heb

[William_H]

Het is inderdaad behoorlijk oud, maar volgens mij nooit absolete verklaard door Microsoft.

Wordt dit ook niet gebruikt in software waarbij je een Word document kan maken? Zoals in EPD's zoals Chipsoft en Epic?

[84hannes]

Het is inderdaad behoorlijk oud, maar volgens mij nooit absolete verklaard door Microsoft.

Dat is ook niet helemaal hoe Microsoft werkt. Producten en diensten worden zelden "obsolete" verklaart, maar eerder "mature". Mature betekent: zo volwassen dat we er niets meer aan hoeven te doen. En dan na jarenlang geen nieuwe ontwikkelingen doen trekken ze stilletjes de stekker er uit en heb je geen verontwaardigde Tweakers die naar de Microsoft Graveyard verwijzen.

Denk aan Team Foundation Version Control en SilverLight. In plaats van abrupt de stekker er uit te trekken heeft Microsoft deze producten gewoon dood laten bloeden en pas toen niemand het meer gebruikte officieel aangegeven dat het product afgeschreven was. Ik weet niet of dat het plan bij OLE ook is, maar het zou passen in hun (gebrek aan) strategie.

[Reactie gewijzigd door 84hannes op 18 juni 2026 21:11]

[Blokker_1999]

Stilletjes? Microsoft kondigt het einde van functionaliteit vaak net jaren van te voren aan langs geijkte communicatiekanalen. Als je dan voor een verrassing komt te staan is het omdat je zelf die kanalen niet opvolgt wanneer ze toch belangrijk voor je zijn. Ik zie nu al EOL aankondigen voor 2028 en later voorbijkomen.

TFS bestaat vandaag nog altijd als Azure DevOps, nieuwe naam, zelfde product. En het klopt dat daar geen ontwikkeling meer aan gebeurt. Aan de ene kant een vrij volwassen product, aan de andere kant hebben ze nu Github.

Silverlight werd in 2015 door MS als EOL verklaard en de laatste versie, Silverlight 5, heeft uiteindelijk, net zoals zovele producten, een support periode van 10 jaar gehad waardoor de EOL datum uiteindelijk in 2021 terechtkwam.

Want je mag wel zeggen dat MS producten stilletjes laat sterven, maar van elke versie die ze uitbrengen kan je rond de release reeds terugvinden wat de einddatum van ondersteuning van dat specifieke product is. Hoeveel andere softwaremakers ken jij die zo open zijn over de levensduur van hun producten?

[84hannes]

TFS bestaat vandaag nog altijd als Azure DevOps, nieuwe naam, zelfde product.

Ik heb het niet over TFS, ik heb het over TFVC. En het wordt waarschijnlijk nog "ondersteund" in de lastigste zin van het woord. Je hoeft al decennialang geen nieuwe features te verwachten en de meeste ontwikkelaars van TFS hebben er waarschijnlijk nog nooit van gehoord. Maar als Microsoft ooit gezegd heeft dat het op sterven na dood was, dan was dat lange tijd na de langste feature update.

[thegve]

Voor TFVC heeft Microsoft bij mijn weten bij de introductie van git ondersteuning in TFS gezegd dat dat de aangeraden vervanger is.

Ik was nog even benieuwd, en ik heb 2 nieuwsartikelen uit die tijd gevonden (helaas niet het oorspronkelijke persbericht).

https://arstechnica.com/information-technology/2013/01/microsoft-embraces-git-with-new-tfs-support-visual-studio-integration/

https://www.hanselman.com/blog/git-support-for-visual-studio-git-tfs-and-vs-put-into-context

Al in die tijd was git gewoon zo dominant/gemeengoed, en het nieuwsbericht is dat TFS "eindelijk" git support krijgt.

Wat 'nu' betreft, TFVC wordt nog steeds ondersteund, maar inderdaad op een 'sterven na dood' manier.

https://learn.microsoft.com/en-us/azure/devops/repos/tfvc/comparison-git-tfvc?view=azure-devops

Git is the default version control provider for new projects. You should use Git for version control in your projects and begin to move your existing TFVC projects to Git. TFVC is considered feature complete. Azure DevOps will maintain compatibility with TFVC, but Git will receive all future investment.

https://learn.microsoft.com/en-us/azure/devops/release-notes/roadmap/2024/no-tfvc-in-new-projects

Sinds 2024, zonder plannen om dit uit te zetten bij services die het nog gebruiken.

[batjes]

Silverlight is een slecht voorbeeld, die heeft Microsoft als overbrugging in de markt gezet, niet als vervanging van Flash, puur omdat HTML5 zo donders lang op zich liet wachten.

Microsoft wacht overigens relatief vaak tot ook de laatste paar gebruikers stoppen met gebruiken alvorens ze er stekkers uit beginnen te trekken en daar valt weinig tegen op te merken.

[84hannes]

Industry observers announced the death of Silverlight as early as 2011.[17] In 2012, Microsoft deprecated Silverlight for HTML5 in Windows 8,[18] but until 2015 it was not clear what Microsoft's official position was on Silverlight's future.[19] In July 2015, a Microsoft blog post clarified that, "… we encourage companies that are using Silverlight for media to begin the transition to DASH/MSE/CENC/EME based designs".[6]

Dat is vier jaar aan onzekerheid. Vier jaar aan developers die tijd en geld investeren in een platform dat eigenlijk al dood is. En precies hetzelfde gebeurt nu voor MAUI: Microsoft verklaart bij hoog en bij laag dat het platform nog in ontwikkeling is. Maar als je gebruikers op Reddit of andere fora leest, dan is er weinig vertrouwen dat Microsoft dit keer door gaat met dit zoveelste UI framework. Zoek maar eens naar "is MAUI dead" en je zult versteld staan van de discrepantie tussen gebruikerservaringen en de officiële standpunten.

[Guru Evi]

Delen ervan zijn wel degelijk obsolete verklaard (oa ActiveX en DDE) en geblokkeerd al van Windows 10 (alhoewel dit maar een regedit is om aan te zetten) Er is ondertussen al lang .NET met COM als de first class vervanging en sinds Windows NT is er ook POSIX-compatibele IPC, er is nooit geen OLE verbinding in Office for Mac geweest noch naar O365 dus het is al een tijdje duidelijk dat aanbieders hun software moeten aanpassen.

Het grootste probleem alsook voordeel is dat OLE al sinds Windows 3.0 ingebouwd zit, dus het zit heel diep in moderne Windows, het zomaar eruit slopen is niet eenvoudig, maar voor veiligheidsredenen zou het wel degelijk dichter gecontroleerd moeten worden.

[Reactie gewijzigd door Guru Evi op 21 juni 2026 01:48]

[NoTechSupport]

Hoe kan een functionaliteit die MS voorziet en die ze zelf breken nu verantwoordelijkheid zijn van externe partijen. Dat is toch totale corporate speak.

[downtime]

Dat kan best. Staat er ergens dat Microsoft garandeert dat een update nooit software kan breken? Het is altijd de verantwoordelijk van een softwaremaker om hun producten na een update te testen en zonodig een update uit te brengen.

[klakkie.57th]

Heeft Microsoft de leveranciers de kans gegeven om dit te testen ? Stond deze wijziging in de release notes ? Kunnen klanten deze update ook on hold zetten ?

Microsoft maakt er zich hier wel heel makkelijk vanaf.

Als je de defacto OS standaard bent, heb je ook een verantwoordelijkheid.

[Dennism]

Maar die zullen dat toch op zijn minst testen met de preview builds? Het is al even geleden, maar bij een vorig werkgever onderhield onze software afdeling ook dit soort plugins voor meerdere klanten. Daar zat ook gewoon een hele teststraat aan vast, waar altijd alle Microsoft updates (OS en alle supported Office varianten) ruim van de voren getest werden, juist om dit soort issues te voorkomen.

[Reactie gewijzigd door Dennism op 18 juni 2026 21:37]

[klakkie.57th]

Dit gaat over een security update dacht ik, daar zijn volgens mij helemaal geen preview builds van … maar ik kan me vergisszn

hmmm zou toch gaan over een gewone update

[Reactie gewijzigd door klakkie.57th op 19 juni 2026 00:32]

[bantoo]

Als iemand die (helaas) ook wel eens meuk voor Excel heeft ontwikkeld, alles in inderdaad oude legacy zooi waar sinds het Excel 2010/2013 door Microsoft vrijwel niets meer aan gedaan is.

En dan heb ik het over de "moderne" manier van werken niet dit soort OLE bejaardentehuis.

Niet heel charmant om dit te slopen buiten een major release maar goed, het zal me verbazen als er nog iemand beschikbaar is bij de leveranciers die weet hoe de software destijds gebouwd is.

[Ablaze]

OLE komt nog steeds veel voor onder Windows, en is gebaseerd op COM dat een core feature van Windows is.

Een bestand slepen in een applicatie -> via OLE objecten

Een afbeelding kopiëren en plakken in word -> via OLE objecten

Een Excel tabel in PowerPoint invoegen -> via OLE objecten


De nieuwe manier (met een hoop html en javascript) is helemaal niet zo krachtig als OLE. Je kunt het niet gebruiken om een document in te vullen vanuit een lokaal draaiende applicatie.

[AMD1800]

Als ik je goed begrijp is daarom het plaatje van het logo in mijn Outlook e-mail handtekening ook stuk gegaan. Dit omdat ik het plaatje ooit in mijn handtekening heb gekopieerd. Dat betekent ook dat ze de collega's die office maken als derden zien.

[William_H]

Maar het is toch idioot als Microsoft iets stuk maakt, en dan zegt dat het de schuld van de ander is. Dat is toch totale waanzin?!

[downtime]

Maar dat zeggen ze niet. Het gaat om de verantwoordelijkheid om het eigen product te ondersteunen, niet om schuld.

[terror538]

Dat deed Microsoft vroeger wel altijd, waarbij ze zo ver gingen dat ze bij bijvoorbeeld SimCity na een free niet het geheugen dealloceerden omdat SimCity een bug had waar er na een free nog met het geheugen gewerkt werd.

[bzzzt]

Dat zijn van die oude verhalen uit de 90s toen Windows nog op floppies geleverd werd en Microsoft zich nog moest bewijzen. Het hele OS is ondertussen geëxplodeerd in omvang en het continu pushen van ongewenste functionaliteit leidt kennelijk amper tot een afname van Windows gebruikers dus als er nu een app breekt is het gewoon pech en jouw probleem ipv een probleem van Microsoft.

[MSalters]

Nope. AppCompat is anno 2026 nog steeds een ding.

Alleen, het is ook al jarenlang zo dat een app compat hack verwijderd wordt als er een security issue door ontstaat.

[graey]

Als het mechanisme van OLE zelf nog blijft werken, maar je interfacet met zaken die niet meer ondersteund worden, is dat aan jou als ontwikkelaar. Extremer voorbeeld: als ik de wereldwijde verantwoordelijke partij voor HTTP zou zijn, en jij hebt een website in HTML4 met misschien hier en daar een javascriptje met hele oude conventies, kan je mij als HTTP-boer er niet van beschuldigen dat ik jouw brakke ouderwetse AJAX-pogingen niet meer ondersteun.

[WargamingPlayer]

MSOLE is al zo oud, dat wil je niet gebruiken. Ik ken bedrijven die nog 32 bit Office gebruiken omdat de integratie anders breekt.

Het houdt een keer op.

OLEDB wordt al niet meer bij SQL Server 2022 ondersteund zonder kunstgrepen. Office 365 ondersteunt MSOLE al helemaal niet meer. Office 2016 is out of support en Office 2019 dit jaar out of support. Dus moet je al voor Office 2021 gaan (wat bijna niemand meer gebruikt).

Bedrijven hebben al jaren boter op hun hoofd, Microsoft is OLE helemaal uit het ecosysteem aan het slopen en het is ook nog eens onveilig.

[_Pussycat_]

Ze bieden het anders wel aan, en hebben het niet als deprecated benoemd. Wat mensen bij office / windows vasthoudt ist juist dat deze spullen blijven werken.

[Cerberus_tm]

Inderdaad: het enige wat mij bij Windows houdt is dat al mijn oude en nieuwer programma's gewoon blijven werken, ook na 20 jaar.

Laatst kwam ik erachter dat het programma van het Woordenboek Latijn-Nederlands van Pinkster niet meer werkt op sommige nieuwe systemen. Ik heb dit denk ik 25 jaar gelden op een cd-rom bij mijn woordenboek gekregen en je kunt de installatiemap gewoon naar een andere computer kopiëren. Mijn computers hebben al lang geen bekerhouders (cd-spelers) meer, als ik de cd-rom al zou kunnen vinden. Maar toch werkt het nog steeds op mijn gewone computer met Windows 10. Je kunt het programma nergens meer krijgen, de uitgever verkoopt het ook niet. (Nu moet ik op de een of andere manier de gegevens uit de software zien te halen, anders gaat het gewoon helemaal verloren.)

[MrMonkE]

Misschien doen ze dingen die je niet moet doen volgens de docs. Heb ik ook wel eens gedaan in een project, wel heel duidelijk aangegeven. Werkte perfect.

[GertMenkel]

Office zit vol verborgen en ongedocumenteerde API's. Als de softwaremakers niet de garantie geven dat die API's altijd blijven werken zoals ze werken (of als de werking via reverse engineering is bepaald en de afgeleide functie niet klopt met wat de interne documentatie zegt), kan iedere wijziging de software kapotmaken.

Zonder een lijst van getroffen API's is het lastig te bepalen, maar over het algemeen wordt dit veroorzaakt door bedrijven die het risico lopen om een of andere feature in elkaar te hacken. Vroeger deed Microsoft nog wel eens een hele hoop moeite om kapotte software werkend te houden, maar dat was een gunst en geen recht.

[Oudecomputer]

Ai code kijkt nergens naar , die mist context waarom bepaalde code zo geschreven is. Oude programmeur weet gewoon er staat hier een pointer om dat Office een F@$_&$# pointer nodig heeft. Dat hebben ze al jaren in de code zitten en iedereen weet af blijven . Ai ziet dat denkt pointer? Die is niet nodig weg er mee want dat wordt niet in Windows gebruikt. En dan krijg je dit soort situaties. En Ai brengt bergen code uit niemand kijkt er naar of het allemaal wel oke is .dat zie je nu ook bij de Linux kernel aantal Ai patches is zo groot dat alle maintainers het gewoon allemaal niet aan kunnen... Van daag of morgen zitten er dikke Trojan back door in je kernel. Snel en veel is niet altijd beter. Liever langzaam en veilig.

[henk717]

Software is niet perfect. Microsoft heeft bijvoorbeeld ook een vliegtuig in GTA San Andreas gesloopt met een update. En toch was dat de fout van de spel makers door het geheugen niet juist te claimen. Normaal zat er niets dus ging het prima, nu zat er wel wat en gaat het stuk.

Kan met OLE ook zo zijn dat ze buiten spec geprogrammeerd hebben en Microsoft bijvoorbeeld een kwetsbaarheid patcht die nu OLE applicaties heeft geraakt.

Of het echt aan de derden licht dit keer weet ik niet, maar het is niet ondenkbaar.

[SG]

Met moderne static compile tools heeft men ook bug of code problemen kunnen vinden in oude quake engines van John Carmack. En dat was al robust. Er zijn hoop sluimerende bug die door edge cases getriggert kunnen worden of API implementatie updates. Bug kunnen lang sluimeren als de kans op edge case zoiets als staatslotery is. Vooral in sandbox games waar game testen veel meer vergt. En dus niet door en door getest kan worden tov corridor of arena game. De 80/20 rule. Want je kan game productie 3 jaar , arena type, half jaar intensief q&A doen wat genoeg kan zijn. Maar complexe sandbox game kan je niet 5 jaar productie intensief volledig testen want dat kan 4 jaar zijn , dat mix in productie kom je op 7 jaar.

Maar dit is dus office legacy probleem van oude software wat oude legacy API van windows gebruikt.

Wat vaker voorkomt in software. En groot probleem is tech debt in software. Wat tijdbom is.

Groot probleem voor software maker en de gebruikers.

[MSalters]

Dit is compleet normaal. Microsoft heeft al tientallen jaren de gewoonte om jaren van te voren te waarschuwen voordat er dingen echt breken.

Geen user settings In C:\Windows schrijven? Jarenlang een advies, maar op een gegeven moment werkte het echt niet meer.

Software kon daardoor met of zonder foutmelding breken. Dat lag niet aan Windows, dat lag aan de error handeling in die software.

[CivLord]

Misschien was de functionaliteit iets toleranter in aanroepen van externe software dan het volgens de specificaties zou moeten. Dat externe software die de functionaliteit dan iets slordiger aanriepen dan volgens de specificaties was toegestaan leverde dan geen problemen op.
Wanneer Microsoft de specificaties strikter gaat volgen, omdat er bv. een mogelijke aanvalsvector mogelijk is door de te ruime tolerantie, dan ligt het probleem toch echt bij de software die de specificaties niet strikt genoeg volgden.

[HerrPino]

Als ontwikkelaar moet je gewoon je code testen tegen developer previews. Dat doen wij ook niet, want ja; zogenaamd 'niet veilig', naief, maar ja dan loop je wel tegen dit soort problemen aan. Het kan best zijn dat Microsoft een bug fixed waardoor je eigen code toevallig wel werkte.

[Soldaatje]

Er zijn wel meer problemen met deze update: https://www.windowslatest.com/2026/06/14/windows-11-kb5094126-issues-include-boot-failures-bsod-bitlocker-recovery-on-some-pcs-hp-onedrive-sync-and-enterprise-apps-broken/
De fix is de update weer verwijderen, of überhaupt niet installeren.

[Harm_H]

Het lijkt dat bij Microsoft en ook bij andere grote software zoals npm iedereen nu alleen nog de core features wilt ondersteunen. Niche packages verdwijnen in de obscuurheid.

Ondanks wat iedereen denkt dat we met AI in een software-boom zitten, lijkt het dat we eerder in een convergentie zitten. Een software-bust.

[abeker]

Volgens mij zit de bug niet in OLE maar juist in COM (maar lastig om precies te zeggen vanwege de verwevenheid van COM/OLE/ActiveX).

Ik heb (helaas) COM-objecten met functies die meerdere parameters van type 'variant' hebben en als ik bij het aanroepen van zo'n functie dezelfde variabele gebruik voor meerdere parameters dan wordt in sommige gevallen de variabele alleen correct doorgegeven aan de laatste parameter van die functie. Wanneer deze bug wel/niet optreedt hangt af van hoe het COM-object is gecompileerd (afhankelijk van gekozen threading model) en hoe het is geïnstantieerd.

Bij de voorbeelden die ik tegenkwam bij gebruikers die tegen problemen opliepen met het programmatisch openen van Word-documenten via COM/OLE wordt de Open functie ook aangeroepen met voor meerdere parameters dezelfde variabele.

De fout zit dus niet in de software van 'derde'/'externe' partijen zelf, dat Microsoft verantwoordelijkheid ontkent is volkomen onterecht!

[zalazar]

COM en OLE zouden misschien vervangen moeten worden door iets dat wel veilig is.
OLE zit er al vanaf Windows 3.0 (1990) in, en COM vanaf 1993
Microsoft blijft maar doorgaan met zaken die qua security eigenlijk niet meer kunnen.
Er zijn zo veel dingen aan Windows te verbeteren maar op moment durven ze nog geen eens Windows 12 op de markt te brengen.
Niemand bij Microsoft durft het aan om die backwards compatibility eens los te laten en een vernieuwend OS te maken. Men zou dan kunnen kijken naar een vervanging of een verbetering van OLE, COM (DCOM), ActiveX, Registry, WMI, Eventlog, Task Scheduler, WinSxS

[Reactie gewijzigd door zalazar op 19 juni 2026 12:10]

[patrom]

Ik vraag me af wat een update voor OS een Office pakket en dan nog van hun zelf in de miserie laat lopen.

[chrome moral]

Doen ze dit alleen voor Spanje of echt overal?

[useruser]

In Nederlandse Windows heet dit een hoera koppeling

[mutley69]

OLE is op de markt gekomen onder windows 3.11 for workgroups. Dat het niet veilig is, dat komt net door die achtergrond. Wat gaat Microsoft ons in de plaats geven? Alles via Azure? Of Onedrive? Een gouden kooi - daarop is de kans erg groot.

[Sp3ci3s8472]

Goh geen foutmelding. Aan de andere kant, de keer dat ik een Windows foutmelding ook daadwerkelijk kon gebruiken om het probleem op te lossen is op een hand te tellen...