Mark Russinovich’s technical blog covering topics such as Windows troubleshooting, technologies and security.
Welcome to the first guest "Case Of" blog post! I've received numerous great troubleshooting cases over the last two months and have selected this one, submitted by Troy Wolbrink, a corporate web master, as the first to share with you.
Troy ran into a problem with his web server and instead of rebooting, reinstalling, or calling Microsoft Product Support Services (who would have undoubtedly suggested the same steps Troy followed on his own, but cost Troy an incident), he used basic troubleshooting techniques to solve it in a few minutes. Like for everyone else that's submitted a well-documented case with screenshots and log files, I sent Troy a signed copy of Windows Internals as a thanks.
I'm including some of the cases I've received in my "Case of the Unexplained..." talk again at TechEd/IT Pro in June. In fact, even if you've watched the webcast from last November's TechEd/ITForum, be sure to come to the session as it consists of entirely new new cases.
Before I present the case, I want to share a clever user-produced video that serves as both a tutorial and demonstration of Zoomit, a screen magnifier and annotation tool I developed as an aid for my presentations. You can find the video here.
Enjoy Troy's post and the Zoomit video and please keep submitting your troubleshooting cases!
The Case of the FrontPage Error
by Windows Detective Troy Wolbrink
I recently transitioned my website from shared hosting to my own dedicated server. Parts of my website were using FrontPage Server Extensions (FPSE), such as the page which collected data and logged the results to a text file:
I installed FPSE using the Add/Remove Windows Components control panel applet, and then I did my best to configure them correctly with IIS. But for some reason I could not get FPSE configured correctly such that my data collection form would work. The error message from the browser was very vague:
I looked for more information in the Event Log on the server, but it had nothing relevant.
My plan was to eventually replace this site with one built on ASP.NET and SQL Server, so I wasn’t feeling motivated to become a FPSE expert just to solve this one problem. But since other priorities are preventing this move to ASP.NET from happening for another year, so I had no choice but to investigate. I had just seen Mark’s talk on “The Case of the Unexplained...”, and I was inspired to run Process Monitor on my server to see if any clues to the problem might appear. I excluded events from some obvious processes that had nothing to do with the problem. This removed a lot of the noise. Since my web page was “TntWebLog.htm” and since it was writing to “TntWebLog.csv” I configured it to highlight anything with a Path containing “TntWebLog”.
To reproduce the problem, I pulled up my web browser and tried to submit the form. Then back in Process Monitor I told it to stop capturing events. I then scrolled down through the list looking for highlighted entries. It was astonishing how quickly I found the problem. FPSE was trying to create the file with the same name as the existing file:
Obviously something was up with file permissions here. I checked the file permissions for TntWebLog.csv and it didn’t have a listing for the IUSR_WEBBOARD account which is what is configured in IIS for anonymous access:
So I clicked Advanced, checked the box for “Allow inheritable permissions from the parent to propagate…” and clicked “OK”:
Doing this caused the proper security permissions to be configured for the file. I ran another test and the problem was solved!
Looking back I believe that this problem occurred because I used Windows Explorer to “Move” and not “Copy” the csv file into place. I did some more tests to confirm this. When you “Move” a file within the same volume using Windows Explorer, the file permissions are moved with it. When you “Copy” a file using Windows Explorer, it creates a new file that inherits permissions from the target folder. If I had originally performed a “Copy” this problem would have never happened.
Now my first reaction to unexplained problems will be to run Process Monitor and see what’s going on under the hood!
Cool, and better for Tony if the prize was a signed book!
Just a little typo: "from the parent to _propoage_"
Thanks for the feedback and the correction, Erwin.
Tony did get a signed book (I indicate that in the introduction).
just one small correction: "When you “Move” a file using Windows Explorer, the file permissions are moved with it. When you “Copy” a file using Windows Explorer, it creates a new file that inherits permissions from the target folder." This is only true when moving files that reside on the same volume (or partition), moving *between* NTFS volumes inherit permissions. A small correction but very crucial to understanding how NTFS permissions differ when moving and copying within or between volumes.
The following line set off an exchange in our internal developer email list:
"When you “Move” a file using Windows Explorer, the file permissions are moved with it. When you “Copy” a file using Windows Explorer, it creates a new file that inherits permissions from the target folder."
I immediately tried to reproduce this behavior on Windows Vista x64 SP1. I created a folder (c:\temp) with very unique permissions. I used right-click and drag-copied from my desktop to the c:\temp folder window and it did inherit the permissions. However, when I used right-click and drag-moved the same file to to the folder, it also inherited the permissions of the folder. This is at odds with the behavior described by Tony.
I then proceeded to make a very simple C# sample (.NET 3.5) to do the same thing, as a developer asked if the behavior described by the guest was the same for MoveFile() and CopyFile():
This sample did reproduce the behavior described by Tony. The file copied.txt did inherit the folder’s permissions, but the file moved.txt kept its original permissions from my Desktop folder.
That didn't make any sense, so I went back and read this blog post and thought about the interpretation of "Windows Explorer". I then used the true-blue Windows Explorer (Windows Key + E) and only moved the file within that window from my Desktop folder to c:\temp. It exhibited the behavior described by Tony and did not inherit the permissions of the folder. Likewise, copying the file only through the Windows Explorer window resulted in the file inheriting the folder's permissions.
So what's going on here? Did the behavior in the Windows shell change at some point? Or are we looking at a bug? Is there a spec for the expected behavior for each scenario, and have these behaviors changed with different releases of Windows (RTMs and Service Packs)?
That's not really a correction, but a clarification. I've modified Tory's text to note that he moved the file within the same volume.
I think "Desktop" file is different,i reproed your saying.
Joel, there is an KB article about the not inherited permissions when moving folders on NTFS Partitions:
It also states that this behaviour has changed in Vista and Windows 2008.
This sometimes also happens on Win2000/2003 fileservers when Users are moving folders on the same share. To prevent problems I'm using Mark's AccessEnum to make regular checks for permissions that are not inherited correctly within the shares.
Mark, thank you very much for your tools. :)
I think the matter of permissions and their intricacies needs to be clarified a bit. Here is what I have learned:
As mentioned above, Windows API, by default, retains all of the file and folder permissions when you move them from one parent folder to another parent folder on the same NTFS volume. For copy operation and move operations to another volume, the destination file always have a new set of permissions, all inherited from its parents.
The reason is obvious to a developer: When you move a file within a volume, no physical data transfer seems to occur; Apparently, Windows only changes the volume Master File Table so that the intended files and folders belong to a new directory entry. This means that Access Control Lists (ACLs) remain unaltered, so even if your Access Control Entries are acquired from a parent. Now, it is arguable whether or not the inherited permissions should be updated with the new parent or not, and whether there is a bug here or not.
However, during a copy operation, or a move operation to another volume, a physical data transfer from one location of the hard disk to another is inevitable. Therefore, Windows API has to build a new ACL for each file and folder entry. These new entries turn out to have permissions inherited from parent.
As demonstrated by Joel Peterson, .NET Framework has the same behavior as Windows API.
Windows Explorer (Windows Shell) tends to deviate from this behavior. According to Microsoft Knowledge Base:
1. On Windows XP, when Simple File Sharing is enabled (default), Windows Explorer always makes sure that all ACLs are reset. This an intended feature that makes using Standard User Accounts in homes and small-business environments more convenient. Note that this only applies to Windows Explorer and Windows Shell, so file operation behavior of programs like Command Prompt are not affected by Simple File Sharing setting.
2. Windows XP, when Simple File Sharing is disabled (domain default) and on Windows Server 2003, Windows Explorer does not alter file and folder permission. This is meant to be an intended defense-in-depth security feature.
So far I don't know the exact behavior of Windows Vista and Windows Server 2008. The KB article which WDoser introduced indicates that Windows now updates ACEs which are inherited from parent but does not explain whether it is a Windows API behavior or only a Windows Shell behavior. To make matter worse, the Applies To section says this article is applied to all editions of Windows Server 2008 but not Windows Vista. (I think it's time I investigate this matter a bit more.)
Unfortunately, the example posted by Joel Peterson also does not help clarify matter with these two new versions of Windows, since it is in C# and therefore uses .NET Framework not Windows API. .NET Framework is supposed to have the same behavior on all versions of Windows; unless otherwise documented in its documentations.
- S. Mahdi Veradi (MCP)
This move problem for site content is not limited to FrontPage, I find it's a common problem when moving any site content.
I get a lot of sites come as installers that install to C:\Program Files\blah\ and don't offer an option to set that folder nor set permissions correctly. When moving to the managed site content folder (C:\Inetpub\ or C:\Sites\ or whatever), weird things happen.
90% of these weird things are because the content was moved, not copied. This is now our first step in troubleshooting. Our second step as always is Process Monitor.
Pre-emptive rebuttal - this isn't an issue of your content is on a different volume following best practices, if you move from C:\blah to E:\Sites the move is a copy.
Nice piece if sleuthing.
Although the error message is still an indication of just how bad software developers are at writing meaningful error handling code.
It's still insane how we have to instantly dive down to the bottom layer to solve these simple problems.
And don't even get me started in the bubbling up of a 32-bit error number to the end user...
I'm still waiting for the "Case of the mysterious idle 12:10am Vista csrss related disk activity that lasts 20 minutes and doesn't show up in procmon even with filters turned off and isn't defrag, system restore, indexing, windows update, superfetch, thumbnail cache updates, trustedinstaller, swap usage, or the drive's idle self test."
Apologies to Troy for reading too fast and using the wrong name in my post.
I'd still like to get some clarification why the behavior is different between right-click plus drag-move from the Desktop to a folder versus right-click plus drag-move from within a single Windows Explorer window.
"I wasn’t feeling motivated to become a FPSE expert just to solve this one problem."
"I wasn’t feeling motivated to become an FPSE expert just to solve this one problem."
If you consult your Chicago manual (or similar) you'll find that the criteria picking 'a' versus 'an' depends on how the phrase *sounds*, not the simple (but incorrect) idea of looking at whether the word begins with a consonant or a vowel.
If 'FPSE' is pronounced as "eff-pee-ess-eee", then using 'an' would be correct.