I’m pleased to say that it looks like one of the features I worked on in the past few months was recently “unearthed” by Neowin. People (and by that I mean power users, enthusiasts, IT admins, and…me) spend too much time trying to navigate around in regedit, jumping around hives. Was that key in HKEY_LOCAL_MACHINE? oh, no, it was in HKEY_CURRENT_USER. Dang it.

So I went and implemented this little nugget that lets you just toggle between these two. Not a huge deal, but it’s definitely nice to hear others might find it useful as well!

Image from NeoWin. I figured since they’re using my feature, I’ll give them a nod and use their screenshot .

Some of our features have been started to get picked up by various tech blogs, including our own Windows 10 blog. One of the features I wrote myself was the new Share integration from File Explorer. This lets you share files through any Store app that participates in the so called “sharing contract”.

http://blogs.windows.com/bloggingwindows/2014/10/13/share-from-file-explorer-in-the-windows-10-technical-preview/

One of the other features my team has been hard at work on is the new landing page for File Explorer, called “Home” in the Technical Preview. This is a new node in File Explorer where we show you your most recently used files, and your most frequently used folders. Pretty nifty!

There are many more features and exciting changes coming! What is your favorite feature so far and what are you most looking forward to?

Looking at what was going on, something was definitely weird. At the point of the crash, my instruction pointer was pointing to garbage. It turns out there is a bug in the class that handles this verb. When that class receives the request to execute your “set desktop background” request, it will dispatch a new thread that will do that in the background. The main thread doesn’t wait for the background thread to complete, and happily continues execution. The worker thread starts executing. At some point, the main thread calls Release() on the last object that lives in the DLL that implements the handler, and that Release causes DllRelease to be called. Once the count of references to this dll gets to zero, we will unload that DLL. That’s how we get our instruction pointer to point at garbage.

This is usually not a problem when you’re setting the desktop wallpaper through explorer because that dll is always loaded in explorer for other reasons so it’s not at risk of getting unloaded prematurely.

So the workaround in the meantime is to LoadLibrary() stobject.dll which is the guy that implements this functionality.

Today I was helping one of my teammates debug an issue he had been looking at for a while. The symptom was a crash here:

HRESULT CGadget::GetPropertyValue(PROPERTYID propertyId, VARIANT *pRetVal)
{
     switch (propertyId)
     {
        case PropertyValue1:
             ...; break;
         ... ad nauseam ...
         default:
             pRetVal->vt = VT_EMPTY; <<<<< CRASH!
     }
}

and at this point in time, pRetVal is null, and propertyId is some bogus value. Hmm, interesting. Tracing it back, we see that there is a thread in a loop accepting requests from other threads and dispatching the appropriate type of request (after all this is in a popular UI framework…) and depending on the type of request, different parameter types will be used. The request that makes everything happens to be one for getting the gadget’s bounding rectangle which just redirects to somebody else’s implementation:

HRESULT CGadget::get_BoundingRectangle(Rect *pRect)
{
    return _pHostedControl->get_BoundingRectangle(pRect);
}

However we see that the disassembly for the call to CGadget::get_BoundingRectangle instruction is actually calling into our CGadget::GetPropertyValue…and even worse, the value being passed as the propertyId parameter is the value of the pointer pRect!  So what’s going on?

It turns out that CGadget has an interesting multiple inheritance structure, where it implements a number of interfaces, in our simplified example let’s call them Interface1 and Interface2.
get_BoundingRectangle happens to be the on the 5th slot in Interface1’s vtable, and GetPropertyValue happens to be on the 5th slot of Interface2’s vtable.

The guy that holds the reference to CGadget actually only talks to it through Interface2, but this interface is being obtained in a somewhat peculiar manner:

CTrinket::CTrinket(Interface2 *pI2)
{
    _pI2 = pI2;
}

void CGadget::DoThings()
{
    CTrinket *pTrinket = new CTrinket(reinterpret_cast<Interface2*>(this));
    pTrinket->DispatchTrinket();
}

So here it is, the culprit is that the code is doing a reinterpret_cast on an interface – even though we know the object inherits (implements) from this class/interface, reinterpret_cast will not fix up the offsets so that the pointer returned points to Interface2 – it will just grab the memory address of the this object and treat it as if it already has a pointer to an Interface2 object; the problem is that the in-memory layout for CGadget, has an Interface1 at the start, and the Interface2 objects starts sizeof(Interface1) bytes later!

This is one of those cases where a C-style cast (or really, a static_cast) would likely be the appropriate choice instead.

Edit: or actually, don't even cast it, as the compiler will know how to cast this into one of its base classes (thanks Raymond for pointing that out :))

tracert -h 99 216.81.59.173

You'll get something like this:

<initial routing...>
 13 * * * Request timed out.
 14 150 ms 153 ms 144 ms Episode.IV [206.214.251.1]
 15 152 ms 147 ms 143 ms A.NEW.HOPE [206.214.251.6]
 16 146 ms 148 ms 147 ms It.is.a.period.of.civil.war [206.214.251.9]
 17 147 ms 145 ms 148 ms Rebel.spaceships [206.214.251.14]
 18 145 ms 147 ms 150 ms striking.from.a.hidden.base [206.214.251.17]
 19 144 ms 150 ms 143 ms have.won.their.first.victory [206.214.251.22]
 20 145 ms 142 ms 145 ms against.the.evil.Galactic.Empire [206.214.251.25]
 21 143 ms 145 ms 147 ms During.the.battle [206.214.251.30]
 22 155 ms 153 ms 147 ms Rebel.spies.managed [206.214.251.33]
 23 156 ms 146 ms 153 ms to.steal.secret.plans [206.214.251.38]
 24 145 ms 148 ms 146 ms to.the.Empires.ultimate.weapon [206.214.251.41]
 25 142 ms 171 ms 145 ms the.DEATH.STAR [206.214.251.46]
 26 171 ms 146 ms 153 ms an.armored.space.station [206.214.251.49]
 27 157 ms 151 ms 142 ms with.enough.power.to [206.214.251.54]
 28 161 ms 148 ms 144 ms destroy.an.entire.planet [206.214.251.57]
 29 148 ms 150 ms 149 ms Pursued.by.the.Empires [206.214.251.62]
 30 144 ms 145 ms 147 ms sinister.agents [206.214.251.65]
 31 146 ms 142 ms 146 ms Princess.Leia.races.home [206.214.251.70]
 32 152 ms 149 ms 147 ms aboard.her.starship [206.214.251.73]
 33 151 ms 156 ms 145 ms custodian.of.the.stolen.plans [206.214.251.78]
 34 149 ms 145 ms 147 ms that.can.save.her [206.214.251.81]
 35 149 ms 150 ms 145 ms people.and.restore [206.214.251.86]
 36 152 ms 150 ms 148 ms freedom.to.the.galaxy [206.214.251.89]
 37 144 ms 151 ms 150 ms 0-------------------0 [206.214.251.94]
 38 149 ms 144 ms 151 ms 0------------------0 [206.214.251.97]
 39 149 ms 145 ms 149 ms 0-----------------0 [206.214.251.102]
 40 148 ms 145 ms 146 ms 0----------------0 [206.214.251.105]
 41 146 ms 144 ms 160 ms 0---------------0 [206.214.251.110]
 42 150 ms 151 ms 146 ms 0--------------0 [206.214.251.113]
 43 145 ms 147 ms 147 ms 0-------------0 [206.214.251.118]
 44 147 ms 148 ms 148 ms 0------------0 [206.214.251.121]
 45 149 ms 149 ms 147 ms 0-----------0 [206.214.251.126]
 46 146 ms 149 ms 153 ms 0----------0 [206.214.251.129]
 47 146 ms 143 ms 149 ms 0---------0 [206.214.251.134]
 48 150 ms 149 ms 148 ms 0--------0 [206.214.251.137]
 49 149 ms 153 ms 148 ms 0-------0 [206.214.251.142]
 50 169 ms 146 ms 147 ms 0------0 [206.214.251.145]
 51 149 ms * 260 ms 0-----0 [206.214.251.150]
 52 204 ms 166 ms 204 ms 0----0 [206.214.251.153]
 53 160 ms 153 ms 169 ms 0---0 [206.214.251.158]
 54 181 ms 150 ms 147 ms 0--0 [206.214.251.161]
 55 160 ms 150 ms 149 ms 0-0 [206.214.251.166]
 56 163 ms 151 ms 151 ms 00 [206.214.251.169]
 57 150 ms 153 ms 152 ms I [206.214.251.174]
 58 150 ms 149 ms 149 ms By.Ryan.Werber [206.214.251.177]
 59 152 ms 152 ms 151 ms When.CCIEs.Get.Bored [206.214.251.182]
 60 149 ms 158 ms 148 ms CCIE.38168 [206.214.251.185]
 61 151 ms 150 ms 149 ms FIN [216.81.59.173]

Today’s blog post will be about the “File in use” dialog. You may have encountered this dialog when trying to delete a file that you happened to have already open. In Windows Vista, all you got was “this file is open in another program”. Not very useful, since you then get to figure out which program is holding the file open. In Windows 7 the system will attempt to give you more information by providing the program name, exe name, or…something else…

You can get one of four dialogs:

1. “File is open in <program name>”. This is the most common case. Windows tells you exactly which program has locked the file. You can then switch to that program – assuming there is only one copy of that program and it’s running in your session (another user on the same machine could be holding the file open, or if the file is on a network share, it could even be another user!). Then you close it and retry the operation.
   
2. “File is open in <exe name>”. You may get this dialog if the program that is holding the file open is running elevated. Since explorer.exe usually does not run elevated, it cannot read some information it needs to determine the display name of the program, so it gives you the name of the executable file.
   
3. “File is open in another program”. You get this when you try to delete a folder that contains a file that is currently open. This isn’t extremely useful since it doesn’t tell you a) which file is open, or b) which program is holding it open
4. “File is open in <service name>”
   
   

This one is the most interesting dialog. Why would the Windows Audio service be holding an event log file open?! Madness!

Well, it turns out that there’s only so much Windows can know about who has a file open. The file was really open by the Event Log service, which by default, runs in the same svchost.exe instance as Windows Audio. You can verify this by running “tasklist /svc” in a command prompt:

So how does this work? at the crux of the issue is Restart Manager, a set of APIs that let applications (esp. setup apps/install wizards) query about which program has a certain file in use that they’re trying to update/write to. It also provides APIs to tell those apps to shutdown and restart (the latter requires cooperation on the app’s part to be able to save its state and load this state upon restart). Restart manager however, doesn’t know too much about which part of a svchost instance called CreateFile. All it knows is that a certain svchost instance did it, and so it returns all the names for services running in that svchost instance.

So, that’s why Windows Audio gets blamed for Event Log holding a file open.

          0 - MS-DOS and OS/2 (FAT / VFAT / FAT32 file systems)
          1 - Amiga                     2 - OpenVMS
          3 - UNIX                      4 - VM/CMS
          5 - Atari ST                  6 - OS/2 H.P.F.S.
          7 - Macintosh                 8 - Z-System
          9 - CP/M                     10 - Windows NTFS
         11 - MVS (OS/390 - Z/OS)      12 - VSE
         13 - Acorn Risc               14 - VFAT
         15 - alternate MVS            16 - BeOS
         17 - Tandem                   18 - OS/400
         19 - OS/X (Darwin)            20 thru 255 - unused

Now, interestingly, it seems that Mac OS is tagging the zip archives it creates with the value 3 (UNIX). Ok, so far no problem, I guess.

The problem happens when Windows gets confused about how to interpret file/folder attributes. In FAT/NTFS, these values are stored according to this definition of File Attribute Constants. You’ll see that FILE_ATTRIBUTE_ENCRYPTED has a value of 0x4000.

The interesting part is how Mac OS is storing its file attributes in the zip archive. Mac OS, being a UNIX based OS, uses the UNIX file/folder attributes system (and permissions, but that’s a topic for another time…).. Well, it just so happens that in POSIX, the flag to describe a directory/folder (S_IFDIR) coincidentally also has the value 0x4000. So it turns out the zip decompression code wasn’t aware that there might be other operating systems out there that might create zip archives…

Bonus question: can you change this behavior. Answer: No; but you can clear the encryption flag from the extracted files/folders easily.

My customers engineer requests to connect to a user’s machine via remote assistance.

The user accepts and the engineer requests to take control.

The user ticks the box to allow the engineer to respond to UAC prompts – then selects Yes.

However – this change requires admin rights and the user is prompted for admin credentials (which they obviously don’t have)

Is there a way to work around this?

Why, yes! Enter UIAccess.

The way Remote Assistance “remote control” feature works is through an OS feature called UIAccess, which allows the app the ability to control the desktop programmatically. By combining this with RDP/TS, Remote Assistance is able to provide the “remote control” feature.

However, in order for this to work properly in scenarios that prompt for elevation (i.e. UAC prompt), you have to enable a certain group policy:

User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop

What this will do is it will enable Remote Assistance to show the UAC prompt on the user’s desktop, as opposed to the secure desktop. If you don’t enable this, the user being helped (call him novice) will get the prompt on his local machine – so the expert cannot interact with it since RA will only remote out the user’s desktop. At that point, the novice may not know what to do with it, and/or he may not have the administrator password. So it is important that you enable this group policy in order to have the UAC prompt show up in the user’s desktop and have RA remote out this dialog to the expert’s machine.

However, there was a bug with RA and how it determined where to show the UAC prompt. However I’m happy to say that my team fixed this bug recently, and you can now download a hotfix that should fix this issue.

You can download this hotfix here: http://support.microsoft.com/kb/2614066 (“Black screen during a Remote Assistance session in Windows Vista, in Windows Server 2008, in Windows 7, or in Windows Server 2008 R2”)

More information:

• http://blogs.technet.com/b/dst2007/archive/2012/03/07/hotfix-available-for-chile-dst-change.aspx 
• http://blogs.technet.com/b/latam/archive/2012/02/27/chile-dst-2012-fallback.aspx
• http://www.microsoft.com/chile/cambiodehora/

Also, my team is hiring!

• Senior Development Engineer

As Raymond explained it in his blog, apps want to make sure you get their notification, they’ll do anything to make sure you do! (including totally and completely unsupported hacks). Apps will even try to spoof other application’s icons, i.e. disguise themselves as a different app to “steal” that other app’s icons’ promotion state. To prevent this and keep the user in control and keep annoying apps at bay, logic was added that would register the path to the executable registering the icon the first time, and if a different executable tried registering the same icon, it would just be hidden. Sounds like a fairly straightforward approach.

The problem is, what if an app’s vendor decided to change the installation folder for their app? For example, imagine the app is installed to “C:\Program Files\MyApp 9.0” and they wanted to release version 10.0, which installs to something like “C:\Program Files\MyApp 10.0”. Since we verify that the path of the calling process’ exe is the same as the exe that registered the icon, this would cause this scenario to fail.

We decided it was probably a fair thing to do to let ISVs manage their own icons, so that they can use the same icon object from the two versions. But how would they that?

The resulting design was that, if the path check failed, we would check the signature in the exe (and store it when you first run the app). If both the old and new exes have signatures, and the Publisher field matches, then we would allow the icon to be taken over.

This new behavior is included in Windows 7 SP1/Windows Server 2008 SP1, and also in a “stability and reliability update” described here and downloadable here. The behavior is also documented as an addendum to the MSDN documentation for the NOTIFYICONDATA structure in the Troubleshooting section:

The path of the binary file is included in the registration of the icon's GUID and cannot be changed. Settings associated with the icon are preserved through an upgrade only if the file path and GUID are unchanged. If the path must be changed, the application should remove any GUID information that was added when the existing icon was registered. Once that information is removed, you can move the binary file to a new location and reregister it with a new GUID. Any settings associated with the original GUID registration will be lost.

This also occurs in the case of a side-by-side installation. When dealing with a side-by-side installation, new versions of the application should update the GUID of the binary file.

Note  The only exception to a moved file occurs when both the original and moved binary files are Authenticode-signed by the same company. In that case, settings are preserved through the move.

This new design/addendum to the behavior took fairly long to implement and get right, so you can say the engineer testing this and I “grew fond” of this code  

Anyway, hope my story “infotained” you, let me know in the comments section what you’d like to hear about next!