Windows 10 Fall Update (1511) APC_INDEX_MISMATCH

TL;DR: This page is getting a lot of views as the Win 10 deadline approaches. If you have a Dell machine, boot in safe mode or remote in via remote desktop and rename the file “C:\Program Files\Realtek\Audio\HDA\RtkNGUI64.exe”. This should allow you to boot without the blue screen.

So we rolled out the Windows 10 Fall Update (1511) to a couple of PCs at the office that were running Windows 10 RTM. Every machine appeared to upgrade fine, but once any user logged into the PC, it would throw up a frowny-face blue screen stating that “Your computer experienced a problem and needs to restart”. The “if you want to know more” reference was listed as “APC_INDEX_MISMATCH”. Searching around for this points to a driver issue, though there wasn’t really an indication of what exactly it might be.

There wasn’t enough time between the login and the blue screen to do any troubleshooting, but there were a few interesting notes:

  • The PCs could stay at the lock screen or the login screen indefinitely. The blue screen only occurred AFTER logging in. This would indicate that the issue is unlikely to be a driver, as drivers would load prior to logging in.
  • The blue screen appeared after login regardless of network connectivity. Wire plugged in or not, right after hitting the desktop the system would crash. The implication here is that the problem is something already on the PC as opposed to something running in the network logon script.
  • All of the machines were Dell Optiplex desktops, but several different models.

Taking these items together, it would seem to point to a startup program. To test that, we could boot into safe mode (which doesn’t run startup items) and disable them. Microsoft has made it quite a bit harder to get into Safe Mode on Windows 8/10 (especially since this blue screen isn’t happening during startup, so it doesn’t trigger the repair mode automatically), but that is where we needed to turn to solve the problem.

If you aren’t familiar with getting into safe mode on Windows 10 (when you can’t get to the desktop to do it through the menu, anyway), power up the machine and wait for the Windows Logo to appear and the “busy” circle to start spinning at the bottom of the screen. Hold down the power button and shut the machine off before it boots up. Repeat this process a couple of times, and instead of the spinning busy circle, the text “Starting Automatic Repair” will appear. Let this run and you will be presented with a couple of tiles on the screen. Click on the Advanced options tile, and click on Startup Options. You will be asked to reboot again. Do so, and a startup options menu will appear. Select Safe Mode (or safe mode with networking, etc).

To solve this particular problem on our Dell machines, after booting into Safe Mode, open Task Manager, click on Details, and click on the Startup tab. We started by disabling all of the startup programs and rebooting into normal mode. This allowed us to log in without the blue screen.

After that, it was just a matter of starting each of the startup items until we hit a blue screen. The culprit for us turned out to be “Realtek HD Audio Manager”. The executable is located at “C:\Program Files\Realtek\Audio\HDA\RtkNGUI64.exe”. Running this .exe file immediately blue screens every PC we have tried it on that has the fall update installed.

I’m sure there will be an update for this eventually, but since you can’t even run updates while this error persists, it can be a real pain to get your PC back in working order. You can avoid the whole problem by disabling this startup executable prior to updating to the Windows 10 Fall Update.

Email Clutter in Office 365

I have a personal Office 365 account, and have managed O365 in an enterprise environment for about a year now. Several months ago, Microsoft quietly introduced a feature called “Clutter” – it showed up on day as a folder in my mailbox with a single message which explained what Clutter in Office 365 is and a link to turn it on. Last week, Microsoft announced that they will be enabling the Clutter feature by default on all Office 365 mailboxes if users haven’t already specifically turned it off.

What does it do?

Clutter pays attention to how you interact with messages in your mailbox and determines what messages you are likely to ignore. As similar messages arrive in the future, it redirects them from your Inbox to the Clutter folder where you can browse through them at your leisure. If you move particular messages out of clutter and back to your inbox, it will learn that you don’t want those items to be classified as clutter and avoid doing so in the future.

How is this different from Junk E-Mail or Spam Filtering?

In a couple of ways, actually. Spam filtering usually uses pattern matching against known spam e-mail or message analysis that determines the likelihood that the message is spam. Messages that get filtered out at this point never hit your mailbox at all.

Those that make it past, but are still of questionable value may get directed to the Junk E-Mail folder. Items in this folder are restricted – they won’t download images, and you can’t click on links in an e-mail in your Junk folder. You have to move it out of Junk before you can interact with it.

Clutter works a bit differently. Items in the Clutter folder are still interactive. You can work with them just like you can with items in your Inbox.

On by Default?

Clutter is actually a pretty nice feature – I have been using it since it was released, and it tends to catch all of the automated status messages from system monitors, along with near-spam messages that make it past the various filters in place. In about two weeks, it will be enabled by default on existing O365 accounts as well as new ones. I can see this initially being a source of confusion to users, since they may not see messages they are expecting to see.

According to the announcement above, when the on-by-default goes live it will include periodic messages indicating what kinds of things are being directed to Clutter, which will be good – right now there is no indication other than the unread count number next to the Clutter field increasing.

There is a PowerShell command included in the announcement above to disable Clutter for your existing user accounts, but as you create new accounts you will have to return to PowerShell if you want to disable Clutter for them – it will be on for newly created accounts with no way to make “off” the default setting for your tenant.

The other good option, of course, is to just let your users know it is coming. This can be especially important considering they will begin receiving e-mail messages with links in them that they are not expecting to receive otherwise – and how many times have we urged users to never click on links in e-mails they weren’t expecting to get 🙂

Shellshock Bug : How to Patch bash Manually

I have a number of Linux system, including several virtual machines with various distributions running everything from test web servers to a Minecraft server for my daughter, and a Raspberry Pi that gets its SD card swapped out all the time depending on what I need it to do. While most of these systems can be automatically updated via yum or apt-get to install new versions of packages, a few are running distributions for which update packages are not readily available.

This doesn’t mean that I can’t secure them against the recently discovered Shellshock vulnerability. I just needed to compile the bash software from the source code, including the Shellshock patches, and install it. That is actually not nearly as complicated as it might sound. Here’s how to do it:

Continue reading

Resolving Windows Update error code 80246002

I don’t know exactly what sequence of updates caused the proliferation of the 80246002 errors when attempting to run Windows Updates, but it appears to be a fairly wide-spread problem on Windows 7 machines.

The problem manifests itself as an inability to manually search for Windows Updates. If you are on a domain that uses a Software Update Server, this check is done by selecting the “Check Online for Updates from Microsoft Update” link at the bottom of the Windows Updates window. Typically the manual check will quickly fail with the error code 80246002.

Searching the net for a solution comes up with a few suggestions, most commonly to change your DNS server to (Google’s DNS) and try again. This does seem work to allow for updates to be downloaded immediately, but it doesn’t solve the problem going forward (you will have to do it again the next time you want to check for updates), and you can’t access any of your local domain resources until you switch it back.

A co-worker and I discussed this problem yesterday, and she worked out a procedure that has corrected the problem on all of the PCs we have tried it on so far:

  • Open Windows Update from the Control Panel
  • Click on “Change Settings” on the left hand side of the screen
  • Uncheck “Give me updates for Microsoft products and check for new optional Microsoft software when I update windows”
  • Restart the PC
  • Optional – I suggest completing the rest of this process and seeing if it works before you do this step, as this will eliminate your Windows Update history. If after completing the procedure you still receive errors when attempting to check for updates, try the following to remove the directory Windows Update uses to store the items it downloads (It will get recreated when the WUAUSERV service is restarted):
    • Open a command prompt as administrator (Click Start, type CMD, right click on the “cmd” entry at the top of the start menu and select “Run As Administrator”)
    • Run the command “net stop wuauserv”
    • Run the command “CD %WINDIR%”
    • Run the command “RENAME SoftwareDistribution SoftwareDistribution_Old”
    • Run the command “net start wuauserv”
  • Open Windows Update and check for updates. Install any updates other than the language packs.
  • When prompted, restart the PC
  • Open Windows Update again and click on the “Find Out More” link which talks about getting updates for other Microsoft products. This will take you to the Microsoft Update page.
  • Install the Microsoft Update client and check for updates.

After that, manually checking for updates seems to work normally on the machines we have tested. It seems that reverting back to Windows Update and then opting back in to Microsoft Update repairs the problem with the update client on the PC.

Some extra keywords for searches : 0x80246002, Microsoft Update, Windows Update, errorcode, fails, Windows 7, Win7, Win 7, search for updates, check for updates, manual update, manually update, wus, wsus, software update services

Active Directory Authoritative Restore

One of the things I hope to do with this blog is post tidbits of information that I come up with after resolving an IT-related problem. Things that were not immediately obvious when searching around the internet to research the issue. Hopefully if other people run into the same problem, they will be able to benefit from these posts. Of course, all of the standard disclaimers apply – this worked in the environment I was in. Your environment might be different. Always backup first, your mileage may vary, etc 🙂

Over the weekend, I was asked to assist with a problem. About 500 user accounts had been accidentally deleted from an organization’s Active Directory. Their AD domain is a child domain of a larger forest, and the deletion had come from a user in the domain above them.

The network in question was running Windows 2008 R2 for some of their domain controllers, but several were still Windows 2003, so the functional level was still at 2003. This means that the Active Directory recycle bin feature was not available. Given the size of the deletion, it was necessary to perform a restore from backup.

Once we had done the tape-based restore, blocked incoming sync traffic, and marked the objects on the restored domain controller as authoritative, we attempted to use repadmin to push the changes out from the restored DC with:


repadmin /syncall (dc name) /e /A /P /d /q


and monitor the replication with


repadmin /showreps (neighbor dc name)


But we kept receiving an error message from /showreps stating that:


Last attempt @ YYYY-MM-DD HH:MM:SS failed, result 8418 (0x20e2):
"The replication operation failed because of a schema mismatch between the servers involved."


Upon investigation, it turned out that the admins in the parent domain had issued a schema update related to a custom AD attribute on the same day as the deletion took place, meaning that the NTDS backup from the night before did not contain that schema update, but did contain the user accounts and group membership that needed to be restored.

The solution turned out to be ensuring that the objects in the restored DC were authoritative and then enabling incoming replication traffic on the DC:


repadmin /options (ServerName) -DISABLE_INBOUND_REPL


This allowed the schema update to complete, which enabled replication between the restored DC and the rest of the domain. After this was done, the /syncall replication performed normally. We then performed a second push to ensure group memberships were updated. When doing an authoritative restore it is possible that group membership lists will be pushed before user accounts are created, so when the group is replicated the users that don’t yet exist won’t be in the replicated group. Pushing the groups a second time (after all of the user accounts are replicated) resolves this problem.

All in all, it took a few hours, but the problem was resolved without any major disruption.

  • Advertisement