Thursday, January 4, 2018

Intel NUC Won't Install Windows 10 Fall Creators Update

I've spent many hours trying to install the Windows 10 Fall Creators Update (16299) on my Intel NUC D54250WYK. The symptom was that the update would appear to proceed correctly, reboot, get most of the way through processing the update, reboot again, and return to 15063. When I looked at the updates history, it would say Restart Required, but the restart would never succeed.

The other symptom I saw was that Windows would routinely hang trying to do Shutdown or Restart.

The final solution was to uninstall the following drivers:

  • Bluetooth
  • HD Audio
  • Trusted Platform

Once I did that, Shutdown and Restart started working reliably and the Fall Creators Update installed without incident.

Saturday, August 13, 2016

Installing a Code Signing Certificate, 2016

This is an update to my earlier article about the same subject. This process is much easier than it used to be.

Install a certificate from Comodo 

  1. Use IE11 for your browser for everything related to the purchase
  2. Use Comodo to buy your Code Signing Cert (still the cheapest provider, especially if you go through Tucows and buy a three year certificate.)
  3. When filling out the information during the purchase process, make SURE you click the checkbox to allow the private cert to be exported, or you will be very unhappy.
  4. After your identity is confirmed, you will receive an email from Comodo with a subject like ORDER #12345678 - Your Code Signing Certificate is ready!
  5. Install the new certificate by clicking the link in the email. Again, use IE11, not Edge.
  6. Remove your old certificate. If you are renewing an existing certificate, then keeping the old certificates installed isn't usually useful, and having multiple certificates will break SIGNTOOL if signtool is searching the certificate store. Go to Control Panel / Internet Options / Content, click Certificates, select your old certificate, and click Remove. The old certificate will probably be on the Personal page.
  7. Verify the installation. Go to Control Panel / Internet Options / Content, click Certificates, select your new certificate, and click View in the bottom right. The certificate will probably be on the Personal page.
  8. Make sure you have the private key. Again on the Certificates Page, at the end of the information, right under the "Valid from" dates, you should see something that says "You have a private key that corresponds to this certificate." If this isn't there, you may not have checked the box during the signup process as described in Step 3 above. You will probably need to get the certificate reissued (this is free with Comodo).

Export the PFX file

A PFX file can be used by many third party utilities. One advantage is that PFX files can be created without a password, which is handy in automated builds if you are using SIGNTOOL. You can see the complete process with pretty pictures at PentaWare (via the WayBack Machine). Here's the abridged version:
  1. Go back to the Certificates Page on Internet Options.
  2. Select your certificate
  3. Click Export.
  4. Click Next.
  5. Select "Yes, export the private key."
  6. Click Next.
  7. Select "Personal Information Exchange - PKCS #12 (.PFX)." (If this option is grayed out, then your private key was not imported).
  8. Check the box labeled "Include all certificates in the certification path if possible. THIS IS VERY IMPORTANT.
  9. Click Next.
  10. Provide a password.
  11. Click Next.
  12. Enter a filename.
  13. Click Next.
  14. Click Finish.
  15. To remove the password from the PFX file, use openssl as described in this post.

Sign your code!

If you need some hints on this, see my earlier post.

As of January 1, 2016, all Windows executables must be signed with SHA1 and SHA256. For details, see this excellent article.

Sunday, May 22, 2016

Remote Debugging Visual C++ 2015

This describes how to configure your system to do remote debugging when you are using Visual Studio 2015. There is no installer for the debug DLLs, so you need to work around this problem.

Among other things, these instructions solve this error message:

The program can't start because ucrtbased.dll is missing from your computer.

These instructions take extra steps to handle the case where you are doing DLL builds instead of static linking MFC and CRT.

Note: These instructions should not be used for release versions of MFC and CRT. Those files can be installed with the files in C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\redist\1033.

1. Install the Remote Debug Tools

The version you install depends on the bitness of Windows. Most people will therefore want to install the 64-bit version. It will debug both 32-bit and 64-bit applications.
  • Click on Tools for Visual Studio 2015 on the left.
  • Click Remote Tools for Visual Studio 2015.
  • Choose the desired version. The section on top is for Visual Studio Update 2. The second section is for other versions of Visual Studio 2015.
  • Select the desired bitness
  • Click Download
  • Run the installer

2. Create a shortcut to the Remote Debug tool

Next create a link to the remote debugger on your desktop. Below is the command I used. All security is disabled because I'm the only user on my local network. Note the useful "/anyuser" parameter that is very helpful when your test VMs are configured with generic user accounts.

"C:\Program Files\Microsoft Visual Studio 14.0\Common7\IDE\Remote Debugger\x64\msvsmon.exe" /noauth /anyuser  /nosecuritywarn /timeout 10000

3. Copy the MFC and CRT DLL's to your application's Debug directory.

There is no installer for the debug DLLs, so you need to work around this problem.

Let's say your application is in:


Copy the CRT and MFC files as follows. Change MYARCH to be x64 if you are debugging a 64-bit application. This depends on the bitness of your application, not the bitness of Windows.

set MYDEBUG=C:\Projects\MyApp\Debug
set MYARCH=x86

copy "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\redist\debug_nonredist\%MYARCH%\Microsoft.VC140.DebugMFC" %MYDEBUG%

copy "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\redist\debug_nonredist\%MYARCH%\Microsoft.VC140.DebugCRT" %MYDEBUG%

4. Copy ucrtbased.dll into your application's Debug directory

The Universal CRT DLL is from the Windows SDK. It is not in the Visual Studio directory. This is a new file required as of Visual Studio 2015. Make sure you set MYDEBUG and MYARCH as shown in the last step.

copy "C:\Program Files (x86)\Windows Kits\10\bin\%MYARCH%\ucrt\ucrtbased.dll" %MYDEBUG%

Note that the discussion on MSDN about ucrtbased.dll being part of Windows 10 is wrong.

5. Define a network share

Create a network share to your Debug directory. It's a lot easier than copying files around. Let's assume you shared your entire C drive. You can share read-only.

On the VM, mount it as a standard drive. I like to use K:.

Finally, in Visual Studio, in the debugger properties, set the application location to use the network share as the path.

6. Run with remote debugging

Start the remote debugger msvcmon.exe on the VM using the shortcut you created in Step 2.

7. Run the debugger in Visual Studio

Sunday, May 17, 2015

Fix for "ICWrapper.dll failed to register" when installing QuickBooks

QuickBooks, how many ways do I hate you? Let me count the ways.

Every version of QuickBooks I've ever installed has had horrible install bugs that made installation difficult or impossible. For five years I couldn't print anything because QuickBooks didn't support printing in 64-bit Windows. The newest version, QuickBooks Pro 2015, has yet another problem.

The error is:

ICWrapper.dll failed to register

If you search the web, you will find many people who are unable to install QuickBooks because of this error. The pathetic part is that the solution is easy. Install the VC90 redistributable (the 32-bit version). It can be found at:

Intuit, are you listening?

Here's a really really easy solution for Intuit that will save your customers endless frustration. Try installing QuickBooks on a Windows clean machine. That's a version of Windows that's just been installed with nothing else. No Microsoft Office. No Visual Studio. Especially no Chrome and no Firefox. Just the latest security updates.

Once you've installed QuickBooks (assuming that works), try testing things like printing.

This would trivially have found the problem on Windows 8.1.

Here's how to debug this particular problem. Perform the following steps:
  1. RegSvr32 ICWrapper.dll. You'll get an error about an error in the side-by-side configuration.
  2. Open the DLL in Visual Studio. The resource section should appear.
  3. Open RT_MANIFEST.
  4. Notice that it wants vc90, version 21022.
  5. Now look in %WINDIR%\WinSxS
  6. Notice that Windows 8.1 includes 30729.1, not 21022.8. Therefore it won't run, especially since your manifest doesn't allow later versions.

Monday, March 17, 2014

Intel NUC - Can't re-enter BIOS through F2

This blog entry is about how I solved the problem where I was no longer able to enter the BIOS using F2 on my Intel NUC D54250WYK.

The problem started when I upgraded my BIOS from 22 to 25 and enabled SecureBoot. Once I did that, the NUC would boot directly into Windows without showing the NUC boot logo nor the F2/F7 prompt.

This is not an uncommon problem. In my case, it took a combination of solutions to solve the problem.

First, the fact that the NUC logo wasn't showing was a clue that the NUC BIOS wasn't detecting the monitor properly. Apparently there's some sort of detection for the monitor to support 1024x768. This detection seems flaky. I tried the DisplayPort connector on two separate monitors without success.

The solution for this problem was to use an Apple mini-DisplayPort to DVI adapter to go from mini-DisplayPort on the NUC to DVI on the monitor. Once I connected the monitor in this manner, the boot screen showed up immediately. I got the idea from this article, which recommended mini-DisplayPort to HDMI.

The 1024x768 detection is particularly problematic if you are connecting the NUC to a TV or through a receiver. In these cases, you may need to connect to a "real" computer monitor.

The next problem was the SecureBoot prevented the BIOS from showing. To solve this it was necessary to enter Maintenance Mode, as described at

Intel NUC - Three flashes and won't boot

This blog entry is about how I solved the problem where my Intel NUC D54250WYK wouldn't boot after I upgraded my BIOS from 22 to 25. (I should have paid to attention to the note that said, "Don't install this if you don't need it." However, I was installing Windows 8.1 and I wanted to make sure I had the latest fixes.)

The symptom was that the NUC would turn on, would flash three times, wait a few seconds, flash three times, and then turn off.

I was running the NUC with 16GB of DDR3 1866 (PC3 14900) Laptop Memory. This memory is faster than most users run, but recent versions of the BIOS are documented as supporting this speed of RAM.

I tried taking out one of the DIMMs, which had worked for me in the past. However, this didn't work this time. (If you try this, make sure you take out the correct DIMM. The NUC will operate on one DIMM, but this configuration is only supported for one of the two slots.)

Eventually I just left the NUC alone for half an hour in its reboot cycle. It eventually booted successfully and the problem did not come back.

Followup, Oct 2014: My system would crash every couple of weeks after I wrote this article. I finally ran Windows memory tests, which failed. I changed the NUC BIOS to slow down the memory and it worked fine after that.

Sunday, January 13, 2013

Outlook 2010: Fixing "An object could not be found"

I just wasted most of a day troubleshooting Outlook 2010 giving me the error message, "The operation failed. An object could not be found."  I'd like to thank Malik Shadid, who wrote a long and very useful blog post that pointed me to the tools below that helped find the solution.

Important: There are MANY things that can cause this error, most of which I'm not remotely qualified to diagnose. Therefore, I cannot answer questions about these procedures. This post describes my experiences, yours may be quite different.

The symptoms were as follows:
  • Outlook would give the "object could not be found" error when trying to download the Offline Address Book (OAB) from the Send/Receive | Send/Receive Groups | Download Address Book.
  • Attempts to create a new profile in Outlook would hang for at least several minutes.
  • Outlook 2007 and 2010 talking to Exchange 2007, all on a LAN.
  • The LAN is a small business LAN that had a new provider and a new firewall/router. 
  • Exchange was running under Hyper-V.
  • Configured for direct RPCs, not RPC-over-http.
  • The OAB did not have the latest changes from the GAL.
  • The OAB had worked before the new router.
  • The problem appeared on multiple computers.
  • Outlook would connect and download mail/contacts/calendar successfully.
My first thought was that my firewall settings were wrong. Indeed, when I looked at the machine running Hyper-V, it had reset itself to be on a "Public Network" and was blocking many ports that it shouldn't have been. So this was the first thing I fixed. Unfortunately, this only made a minimal improvement.


HOSTS file

My next step was to check for DNS resolution. My domain was "abc.local" with the server name being "". For the purpose of testing, I added abc.local,, and jupiter to the HOSTS file in C:\Windows\System32\Drivers\Etc. After doing this, I pinged the host by the various names to make sure it worked. (You do not need to reboot after updating the HOSTS file.) Unfortunately, this didn't fix it either.



At this point it's important to understand that the OAB is a rather strange beast that sometimes uses a different set of protocols (and ports) than MAPI. The OAB can get the connection information from the Autodiscover.xml file, so it's critical that the Autodiscover.xml file be accessible, even in a small test environment. The actual process used to track down the AutoDiscover file is quite complex, as Malik describes in his TechNet blog.

To help find the Autodiscover file, there's an applet in the Exchange PowerShell called test-outlookwebservices that will give you ther URL, as well as telling you whether the server responds to basic "are you alive" tests. It's documented on this  TechNet Page. Here's an example:

[PS] C:\Documents and Settings\JimB>test-outlookwebservices | format-table -wrap -autosize

  Id        Type Message
  --        ---- -------
1003 Information About to test AutoDiscover with the e-mail address Administrat
1007 Information Testing server with the published name http
                 s:// & .
1019 Information Found a valid AutoDiscover service connection point. The AutoD
                 iscover URL on this object is
1006 Information The Autodiscover service was contacted at
1016     Success [EXCH]-Successfully contacted the AS service at https://jupiter
                 .abc.local/EWS/Exchange.asmx. The elapsed time was 31 millis
1015     Success [EXCH]-Successfully contacted the OAB service at https://hamme
        The elapsed time was 0 millis
1014     Success [EXCH]-Successfully contacted the UM service at https://jupiter
                 .abc.local/UnifiedMessaging/Service.asmx. The elapsed time w
                 as 31 milliseconds.
1006     Success The Autodiscover service was tested successfully.

600 Error

To eliminate any firewall or routing issues, I first tried opening the Autodiscover URL in the browser on the server itself.

This yielded the an error 600 with the following content:

<?xml version="1.0" encoding="utf-8" ?>
<Autodiscover xmlns="">
<Error Time="20:34:08.3587762" Id="147247660">
<Message>Invalid Request</Message>
<DebugData />

A half hour of research indicated that the "600" error actually meant that it was working, but it wasn't authenticated. So the above result was actually good.

I tried the same URL from two client computers. It gave the same result in both cases. So all of this looked okay.


Connectivity Analyzer

Malik's blog also pointed me to a tool called the Microsoft Exchange Connectivity Analyzer (beta). (Requires .Net 4.5.) Get the tool from:

After starting the Analyzer, click the Client tab, download the file and install it.

The results of this finally showed me the problem, which was that wasn't resolved by DNS. I put that domain in the HOSTS file, tried the Connectivity Analyzer again and... it failed again. But it got further than last time.

I chased down the errors by clicking the little arrows under each error message in Analyzer. By drilling down, I discovered that it didn't like that my server certificate was for instead of *.abc.local. Fortunately Outlook doesn't care about this, so Outlook works even if the Connectivity Analyzer does not.

The other domain names I mentioned at the beginning of this article also had to be in the HOSTS file, so that effort wasn't wasted.

Test E-mail AutoConfiguration

The next step was to go to a client and use an undocumented feature in Outlook 2007/2010 to test the Autodiscover resolution. Ctrl-right-click the Outlook notification icon on the right in Windows. Select Test E-mail AutoConfiguration. Enter your Exchange email address and your password. Make sure Use AutoDiscover is checked. Click Test.

If it's successful, you can switch to the XML tab and see the Autodiscover.xml file.


Wrapping Up

Finally I backtracked to find out why changing the router broke everything. It turns out that the old router was configured to forward all DNS requests to the Windows Server, which knew how to resolve *.abc.local to the proper server. Anything else was forwarded to Google's DNS. (Google's public DNS servers are blisteringly fast and are definitely worth using. Their IP addresses are and