Excel Crash: Visual Studio (10) Tools for Offce Add-in -- vs10exceladaptor

Solution

Solution thus-far has just been to disable the add-in for all users. We don't know of anyone actively using this add-in so that works for us. If you need the add-in I would look towards compatibility. 0xC0000005 typically indicates that a program tried to access memory it's not allowed to. This could mean another plug-in isn't playing nice, or you might try disabling DEP (though this is a pain for office, and more than a bit of a security risk).

To disable add-in for all users, found the best way was to log in as admin, find the excel executable (excel.exe) > right click > run as admin. Then go to File > Options > add-in > com add-ins > go. Then uncheck the boxe(s) for the "Visual Studio Tools for Office Design-Time Adaptor for Excel".

Story

Had some users complaining about excel crashing on our terminal server. This is a terminal (RDS) server that students use to remotely access lab applications via thin-clients, so it has just about every program under the sun installed on it. I mention this only because this means we have about 1000 different excel add-ins loading/available which is what I expect is causing the underlying issue. Also worth noting, Thin clients connect via XenDesktop (7.1); this could also be a cause of the error.



Other notes on server: Server 2008R2 (fully updated, x64), Office 2013 x86

Looking at the even logs, I see the excel crash (Error, Aplication Error, Event ID: 1000)

Faulting application name: EXCEL.EXE, version: 15.0.4535.1507, time stamp: 0x52282875
Faulting module name: EXCEL.EXE, version: 15.0.4535.1507, time stamp: 0x52282875
Exception code: 0xc0000005
Fault offset: 0x0005a802
Faulting process id: 0x2380
Faulting application start time: 0x01cf9c61a803a93c
Faulting application path: C:\Program Files (x86)\Microsoft Office\Office15\EXCEL.EXE
Faulting module path: C:\Program Files (x86)\Microsoft Office\Office15\EXCEL.EXE
Report Id: ed04ac54-0854-11e4-9867-d4bed9f3434f

Which doesn't give us much. In past experience, 0xC0000005 is a generic "Memory Access violation" error -- a program tried to access memory it didn't have permission to.  The next entry in the even log is a bit more useful (Error, Microsoft Office 15, EventID 2001)

Microsoft Excel: Rejected Safe Mode action : Excel is running into problems with the 'vs10exceladaptor' add-in. If this keeps happening, disable this add-in and check for available updates. Do you want to disable it now?.

This appears to be something that gets installed with visual studio, no idea what it does. I went ahead and disabled it for all users (see notes in Solution) since I'm not aware of anyone using that add-in. Worth noting that I initially tried disabling the add-in through the registry (HKLM\Software\Microsoft\Office\Excel\Addins\VS10ExcelAdaptor\ -- Set LoadBehavior to 0) but that didn't seem to have any effect.

Windows RDS (Terminal Server) - Stuck Applying group policy

Had a lovely time yesterday when the terminal server (2008 R2 running RDS) that our users use to access programs/files from off site decided to tank. Luckily we have a backup server... except that one was tanking as well.

The short version is that, at some point over the weekend, the server began taking inordinate amounts of time applying group policy settings, making user log on take upwards of 5 minutes and killing server performance. Some of the error available in event viewer included

• warning|grouppolicy|eventid:1090|"Windows failed to record Resultant Set of Policy (RSoP) information, which describes the scope of Group Policy objects applied to the computer or user. This could be caused by Windows Management Instrumentation (WMI) service being disabled, stopped, or other WMI errors. Group Policy settings successfully applied to the computer or user; however, management tools may not report accurately."
• warning|winlogon|eventid:6005|"The winlogon notification subscriber <GPClient> is taking long time to handle the notification event (CreateSession)."
• warning|winlogon|eventid:6006|"The winlogon notification subscriber <GPClient> took xxx second(s) to handle the notification event (Logon)."

On the user side you would see "Applying user Policy..." for 5+ minutes while trying to login. When I tried to reboot one of the servers it took (quite literally) several hours to get past the "Applying computer settings" screen. On reboot, in task manager you'd see an svchost process using 2+GB of ram and 100% cpu (limited to one core, so it was ~13% in my case). Killing this process would cause all sorts of interesting errors to occur - best I can tell this was the GPclient service. 

After a few hours of trying different things - notably de-joining  from the domain, which didn't work and took forever - I finally figured out it had something to do with the WMI repository. From command line I tried:

winmgmt /verifyrepository

winmgmt /salvagerepository

Neither of these ever returned anything (let them both run, separately, for 30 minutes).  While either was running there would be a winmgmt.exe process in task manager using 100%/13% CPU and progressively more RAM. So, since neither of those worked I tried:

winmgmt /resetrepository

Boom! Everything was back to normal. It was almost disconcerting how quickly everything started working again. Rebooted the server and it shutdown and restarted in its normal couple of minutes. I have yet to discover exactly what caused the wmi repository to corrupt but at least for the time being users are able to get to their stuff.