The hiberfil.sys file is used with the Windows Hibernate feature, and even if you modify your power plan and disable the hibernation features in there, the file will still be on your system. The file size depends on the amount of RAM your system has, as it is used to dump some (or almost all) of the data in RAM on to your hard drive so it can enter a hibernation state. For my system, since I have 4GB of RAM, the file was almost 4GB in size so it made sense to get rid of it if I wasn’t going to use Hibernation mode.

To get rid of the hiberfil.sys file, open up an elevated (as in, Administrator) command prompt and simply type in:

powercfg -h off

This will turn off the Windows Hibernate features (including disabling them in your Power Options) and with it, delete the hiberfil.sys file from your system so you can reclaim some space (and it also helps with defragmentation of your drive, as it is a system file that cannot be moved; the same thing goes for pagefile.sys, which you can read about in my other article “Give Windows a Swap partition with no drive letter“).

As you can see in this screenshot, there are two particular areas which I consider design oversights when they were apparently overhauling the GUI to make it look nicer. First is the appearance of the “menu” displayed when I expand “Computer” (it would be the same for any folder – I just have the others set to act as links, not menus). It appears as though they decided to use a generic Windows “context menu” container to display the file list, however you would figure that for the nice and fancy new Start Menu that they could have put a bit more “love” in there and made it look more integrated (such as you’ll get if you were to expand one of the items in the Start Menu list such as “Sticky Notes” or “Windows Virtual PC” in this particular screenshot). I think it would have made it look much nicer, complete, and more thought out.

The second pin in my rear is the redesigned Shutdown button and it’s corresponding context menu. It’s just plain horrid! Why couldn’t they have made it look the same as the other items above it like the “Computer” item for example? Or, heck, bring back the much more pleasant-looking Vista Shutdown buttons – those were well designed and I think more intuitive at quick glance; simple red power-symbol button, or having to read “Shutdown” in an ugly, oddly-sized button – what’s your pick?

Perhaps I will spend a few minutes and try to mock-up what I think would look nicer, though honestly I doubt anyone from the Microsoft Windows GUI team will ever come across this post, let alone this site

That may be all well and good (and I do agree, it certainly makes sense), but what if you change the computer name within your XP Mode virtual machine? Well, the answer to that was made abundantly clear to me when I did that very thing (completely unaware of how credentials were saved at the time) just the other day – ultimately locking myself out of accessing any of the applications I had just finished installing in Windows XP Mode.

What happened was somewhat obvious once you look at the information saved in the Credential Manager for a little while; Microsoft Virtual PC was no longer logging me in automatically as the XPMUser – instead it was prompting me to enter the password, or specify an alternate account to log in as. The problem was, I had used a random password generator for the password and never bothered to write it down anywhere (because I figured that the Credential Manager was going to handle that all for me), so I had no idea what the password was and of course the Administrator account is disabled (unless you’re in Safe Mode) so I had no way of logging in any more!

What I did to remedy this situation was a bit old-school. I first changed the virtual machine settings and disabled the integration features so that I would see the boot-up process. As it started to boot, I hit F8 on my keyboard to get the Safe Mode boot prompt and I booted in to Safe Mode. From there I was able to log in to the Administrator account (no password) and then get in to the system and reset the password for the XPMUser account. Once that was done, I just had to reboot the virtual machine again (and reset the settings to re-enable integration features) and enter the new password for the XPMUser account (and save that information with the Credential Manager).

Now my Windows XP Mode virtual machine had the correct computer name for my LAN, and the Credential Manager was able to log me in automatically again when I used Windows XP Mode – yay!

For the longest time ever, I always wished that you could do more than just move your Windows swap file (pagefile.sys) to another drive letter. First of all, having to assign a drive letter to the partition you want purely for storing the Windows page file really sucks because then that means the drive letter shows up in explorer (sure, you can hide drive letters, but you’ve still wasted a drive letter on the partition). Second of all, if you think you’re being smart by creating a partition at the root of your drive during Windows installation, chances are you kicked yourself after going through the install only to realize that it assigned that partition the letter “C:” and now Windows is installed on “D:” (good luck getting out of that scenario – I’d recommend just redoing the install entirely; trust me it saves you a ton of headaches).

Well, since I just got my fancy copy of Windows 7 Ultimate, I figured I would see what I could do finally about this situation. Upon booting up the Windows 7 DVD, I went through the installer up to picking the partition I wanted to install Windows 7 on to. I clicked the Advanced button so I could delete all my existing partitions and set the drive up the way I wanted. With an entirely blank drive, I began by creating a single partition on the drive (entire drive). This let the installer create the special “System Reserved” partition that it wanted. I then selected the other partition it made and deleted that and then created a new partition the size I wanted for my swap. I have 4GB of ram on this system so I want at least double that, plus I may want extra space for something else eventually so I went for a 16GB partition. Next, I created the last partition with the rest of the drive space; this is my Windows partition (C: drive). I selected the Windows partition and clicked Format (do *not* do this for the Swap partition yet!).

The next step was where some of the nerd-magic came in. I backed out of the installer at this point and got back to the main window and clicked on the Recovery link near the bottom. From there I selected the top radio button and then on the next screen I selected the Recovery Console. Once in the console I ran “diskpart” to let me tinker with the partitions I had just created. Using diskpart isn’t too complicated. You can type in “help” to get a list of the commands you can use; it’s not overly complex if you come from a Linux background and you’re used to using fdisk. I selected the Swap partition (volume) I had made earlier and ran “ATTRIBUTES VOLUME SET NODEFAULTDRIVELETTER”. This prevents the system from automatically assigning drive letters to any partitions on this drive – it will still assign “C:”, however the Swap partition will not get a letter. Once that was done, I made sure to list out the volumes just to be sure it didn’t already have a drive letter (it shouldn’t since we didn’t format it yet). I then closed the console, and closed the window with the recovery choices (this brings you back to the start – you don’t have to click Shutdown or Restart!). I then went back through the installation process, selected my Windows partition I had created and let it install Windows 7 to the drive.

After finishing the Windows install and logging in, I thought about how I would actually go about using that Swap partition for the page file without giving it a drive letter. I decided to search the registry for “pagefile.sys” to see what I could come up with and I found that the only real occurrence of it is in “HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management\”. There are two keys in there, PagingFiles and ExistingPageFiles, which reference pagefile.sys and that’s about it. Obviously ExistingPageFiles is not a key we want to modify, however PagingFiles is.

So here’s where the real brains came in to help… I went in to Disk Management and selected the unformatted Swap partition I had created and formatted it as NTFS (with 32k blocks – we don’t need small blocks here… the bigger the better for performance). Then, I opened up Explorer and decided I would have this partition mounted to “C:\Windows\Pagefile” – yup, I’m mounting it to a path, not a drive letter! So, I created the directory and then went in to it’s security permissions. I removed all the inherited permissions and set the following permissions on it: TrustedInstaller (“NT Service\TrustedInstaller” is the account name you must type in to make that work) got full access, SYSTEM got full access and Administrators got Read & Execute access. I then went and changed the Owner to TrustedInstaller as well. Once you do this, you won’t be able to access the folder even as an Administrator – but that’s what we want since we don’t want anything having any access to pagefile.sys except the system itself.

I then went back in to Disk Management and again selected the Swap partition and went in to “Change Drive Letter and Paths…”, clicked Add… and set it to mount to the “C:\Windows\Pagefile” folder I had created. I made sure to confirm that the process had worked successfully (basically just went back in to make sure it was listed in the “Change Drive Letter and Paths…” dialog box). Now that I had my Swap partition mounted to the directory, I just had to change where pagefile.sys would be written (and erase the old pagefile.sys file). I opened up regedit, went to “HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management\” and double clicked the PagingFiles key to modify it. This registry entry allows for multiple pagefiles to be specified, one per line. The 3 different formats it can have are rather simple to understand after having examined it in different configurations.

• The first mode is having Windows manage pagefile.sys for you; the drive letter is specified with “?” to denote that it is whatever drive letter Windows is installed on and then the full path to pagefile.sys is specified (eg “?:\Windows\Pagefile\pagefile.sys”).
• The second mode is managing the location of pagefile.sys yourself, but having Windows manage it’s size; the full path to pagefile.sys is now specified including the drive letter, and then we add two zeros separated by spaces to denote a dynamic minimum and maximum size for pagefile.sys growth (eg “C:\Windows\Pagefile\pagefile.sys 0 0″).
• The third mode is managing pagefile.sys entirely on our own; The full path to pagefile.sys is specified, and then we specify an absolute minimum and maximum size for the file in MB (eg “C:\Windows\Pagefile\pagefile.sys 6144 10240″).

I chose the third method since after some experimenting it appears as though this is the most compatible with the Virtual Memory settings in Windows. Using the first method, Windows doesn’t appear to know where pagefile.sys is or that it is supposed to be managing it for us. Using the third method, it knows that pagefile.sys is indeed located on our “C:” drive and that there are explicit minimum and maximum growth limits specified. It may be only visual, but I didn’t want to chance it with my virtual memory (since running in to the problem when I would need my virtual memory would be a very bad thing).

Finally, to make sure the existing pagefile.sys was deleted (properly), I opened up “Local Security Policy” from the “Administrative Tools” control panel. I navigated to “Local Policies\Security Options” and scrolled down near the bottom of the list to find “Shutdown: Clear virtual memory pagefile” and simply enabled the option. This would take care of deleting the page file at shutdown for me.

That was about it – next was taking a leap of faith and hoping that when I rebooted, everything would still work! So, I crossed my fingers and hit restart and watched as my hard drive light went nuts as it deleted the current pagefile.sys before rebooting. Once my system came back up I went in to Disk Management, right clicked the Swap partition and clicked Properties. I checked to make sure there was some space being used up just to confirm that pagefile.sys was now being stored there instead of my Windows partition – and it was! All I had left to do was go back in to “Local Security Policy” and disable the “Shutdown: Clear virtual memory pagefile” setting.

I had finally done it – I had created a separate partition for Windows to store its page file without having to resort to assigning a drive letter. So far, the only drawback seems to be that if you go in to your system settings to manage your Virtual Memory, it gets a bit confused and indicates that there is no paging file set on your “C:” drive – which I suppose is now technically correct… but I wonder what might happen if Windows tries to allocate more space than is available in the Swap partition for Virtual Memory… I think I may have to peek at some more registry entries to see if I can set the min/max values for Virtual Memory so that can’t happen.

If you’re also wondering about how to deal with the hiberfil.sys file in the root of your Windows drive, you can read up on that in my other post “Delete hiberfil.sys from the root of your Windows drive“.

It’s a real hassle to try and constantly postpone the reboot, not to mention if you’re not at your computer it will just reboot it for you and you could lose any unsaved work! The solution is actually quite simple! Unlike some other sites I’ve seen, the proper solution is not to install and run some 3rd party program that’s sole purpose is to watch for the reboot dialog box and simluate pressing on the postpone button… the thought of ever having to make a 3rd party program to solve a problem in another program is absolutely revolting; that’s the worst solution to a problem you could ever come up with and I’m rather amazed anyone ever even thought of it as a viable option.

The real solution is to change a Windows policy specifically created to solve this problem (yep, that’s right – Microsoft anticipated this would be a feature some may want to disable and gave us a way out… it’s just not available in any easy to use control panel interfaces). We have two choices here: we can fire up the Windows Policy Editor and change it there, or we can just edit the setting directly within the registry. I find modifying the registry directly to be much easier and quicker since it allows a simple 2-click process to change the setting; much easier than having to run a program and find the setting to change it.

All you have to do is download a registry file I created, disable-update-reboot.reg, and right click it and select Merge (as Administrator). You can edit the file to verify that it’s only modifying one string in the registry and that it’s not installing anything malicious. This will disable the Windows Update reboot message from forcing you to reboot. It doesn’t get rid of the message entirely, just prevents it from rebooting automatically without your consent.

I didn’t bother to deal with it for a while since I could just cancel the errored out jobs in my printer queue and not worry about it since the PDF would still be created, however I figured I would finally figure out the problem and try to fix it. Of course, searching on Adobe’s website turned up nothing of relevance, and a few websites I found just said to re-install the Adobe Acrobat PDF printer which was what I figured I should do anyways, so I did.

From what I can gather, the problem may have been started when a new version of Adobe Acrobat got installed. During the process of re-installing the Adobe Acrobat PDF printer, I noticed that my system had two versions of the Acrobat PDF printer drivers; one for version 6, one for version 8. I’m guessing this also causes problems when you try to add a new Adobe PDF port; when trying to do this, it never allows you to actually add it – I’m guessing it’s confused as to which version of the driver it should pick and install.

So what I did to fix this was I deleted the Acrobat PDF printer from my system and made sure I had no Acrobat PDF ports installed (in Windows Vista, right click in the printers folder and select “Run As Administrator -> Server Properties” to add/delete ports). Once I had done that I added a new local printer and created a new port – but I did not select “Adobe PDF Port” since this would not work for me. Instead I picked “Local Port” and named it “Adobe PDF” (I don’t think the name of the port matters, however the name of the printer does). I then selected to use the Adobe Acrobat PDF v8 printer drivers and named the printer “Adobe PDF” which is required otherwise using “Save As” will not work in suites like Microsoft Office. When it was all done I went in to the printer properties and changed it to print directly to the printer (under the “Advanced” tab).

Now saving as an Acrobat PDF document or printing to the printer works just as it did before but without generating any errors that get stuck in your printer queue! As to how you’re supposed to properly remove the older Adobe Acrobat PDF v6 printer drivers from your system, I do not yet know – but leaving them there seems to cause no ill effects.

For the longest time I refused to use the WIDCOMM drivers because their look and feel was stuck in the Windows XP days – it wasn’t horrible, but it didn’t integrate nicely in with Vista and it completely took over the Bluetooth stack which I didn’t want to do because I was afraid it would prevent my Microsoft Wireless Entertainment Desktop 7000 (Bluetooth keyboard & mouse combo) from working.

Well, the other day I decided to replace my old Plantronics Explorer 320 headset (Bluetooth 1.2) with a new Sony Playstation 3 Bluetooth headset (cheap, Bluetooth 2.1+EDR). I went and paired up the new headset with Vista, however the sound was just as choppy as before and it really didn’t seem to be any better; those old Bluetooth Audio drivers I hacked in to Vista needed updating…

I did a ton of searching and came across most of the same articles I found when I was first looking for drivers to add in A2DP/HFP/HSP Bluetooth profiles to the Microsoft Bluetooth stack. I tried grabbing newer drivers for the Dell Notebook Bluetooth drivers, but those didn’t work at all. I went searching for more drivers but they all seemed to be based on the same drivers (ironically all made by Broadcom). As a last ditch effort, I went to Broadcom’s website and grabbed their latest driver download just to see if maybe I could extract the driver files and manually update my drivers without installing the whole thing.

As it turns out however, the new Broadcom WIDCOMM Bluetooth drivers aren’t a complete overwrite of the Windows Vista drivers – they appear to finally just throw in all the extra Bluetooth profile drivers that are missing from Microsoft’s Bluetooth stack. I was quite surprised, as I thought I was hosing my system when I ran the installer to try and just extract the files; the Bluetooth control panel and other areas of Vista all appear just as they did before but with extra features now available!

I paired the new headset with my system and watched as the new drivers kicked in and made everything work perfectly. Rather than being stuck with low-quality mono in/out from my headset, I now get to enjoy stereo sound and recording which makes a ton of difference in the audio quality from a Bluetooth headset.

So, if you’re looking to get your Bluetooth device working with Windows Vista or Windows 7 and it just won’t work – chances are you’re missing the required Bluetooth profile drivers and you should seriously consider installing the latest Broadcom WIDCOMM Bluetooth drivers which will update the existing Microsoft Bluetooth stack on your system.

My first thought was that it might be some code I had recently added to a JavaScript file which was responsible for capturing the name/value pair of the submit button pressed when you submit a form (which is the only way to get that information when using AJAX to submit form data). The code worked great in Firefox, but I hadn’t tested it yet for Internet Explorer at all, so I changed it around a bit to see if maybe some of that was causing it. My debugging progressed to completely commenting out that new code, essentially bringing me back to code I knew worked in Internet Explorer 7 before, but it was still crashing!

I started to dig a bit deeper and noticed that for some reason if I commented out one of my submit buttons (my form had two buttons with the same name – used to pick between two choices… both of which submit the form), it wouldn’t crash any more – but it wasn’t submitting the form via AJAX which it should have been, so there was still a problem somewhere. Since I was able to get a bit further now that Internet Explorer 7 wasn’t crashing, I was able to determine that it was choking somewhere in jQuery, at a piece of code that quite simply just tried to toUpperCase() a string – namely the method of the form (that is, whether it was to be submitted via GET or POST).

I played around a bit and noticed that if I hard coded in (to my JavaScript code that builds the form data to be sent via AJAX) a method of “post”, that it worked fine – it didn’t like it when I tried to retrieve the method set on the form however. After a bit more sleuthing, I decided to check up on the getAttribute() DOM function which I used to try and retrieve the form method. What I found was a piece of gold buried under the usual MSDN documentation; someone had posted a comment at the bottom mentioning an obscure bug when using getAttribute on forms… At first, I was a bit excited, hoping I had found the problem but I quickly saw that the bug was apparently just mentioning a problem when you used the name “id” on an input element which I was not doing in my code. However, I kept reading the description and noticed there was an additional bit of information stating that the problem was that the name property on an input element could actually override any key word in the DOM, potentially causing odd behaviour.

I quickly skimmed through my form, looking at the inputs and what name I had assigned them, but they were all fine, however the submit buttons were named “method” – which is a DOM property for forms! The comment quickly made sense and I knew I had found the problem; the submit button was causing a problem when I was trying to get the method property from the form through getAttribute()… it was clashing with the name property from the submit button because it’s name was set to “method” and this was causing Internet Explorer 7 to crash!

The fix was relatively simple – I just renamed my submit button to something other than “method” and presto, Internet Explorer 7 now worked just fine (and I was able to re-enable my second submit button without any problems too). Well, I shouldn’t say fine since I did discover another problem in that Internet Explorer 7 apparently submits the HTML code in between<button>…</button> tags instead of the value property defined on the button element, but that was a simple work-around thankfully.

Stupid Internet Explorer

I’m talking of course about Brian Wilson’s Index DOT Html and Index DOT Css sites. I have been using these sites over the past 8+ or so years as one of my primary resources when it comes to Web Development. They document the majority of the HTML and CSS elements and properties, how they work and what browsers support them (and to what degree) – complete with browser specific tips and notes.

The sites may not be up to date with Firefox 3 and Internet Explorer 7 or 8, but the information they provide is still very relevant and still very useful. They’re always my first stop when I need to look up a particular HTML element or CSS property, and to be honest I don’t know where I would turn if they weren’t around for me to use. I suppose I owe Brian Wilson an enormous thank you for all his hard work and dedication to the sites, and I’m pretty sure that there are many others out there who owe the same as well.

Brian, thank you for two of the most useful resources available on the Internet over the past decade or so.

After doing some initial debugging, it seemed that my responseText was coming back blank – but Firebug clearly showed that Firefox was getting the full DOM document back from the AJAX POST call, so I knew something was up with how the response was being handled by AJAX. Now, I use jQuery for the majority of my JavaScript code, so I was a bit surprised to find out that there was an AJAX problem since I figured that a bug like this would have likely at least already been reported. After a lot of searching on Google however, I only turned up one result that was quite similar to my problem which had no resolution. So it looked like I would have to solve this one entirely on my own.

I did more debugging, and out of pure luck I ended up noticing that the readyState on my XHR object was set to 0, which means that apparently an AJAX call hadn’t even been made yet. I found this rather odd to see a readyState of 0 since clearly an AJAX call had been made (and returned with success). I thought about the situation a bit and figured that perhaps I should move my debugging call (I was using console.log()) up the chain a bit so I did it as the first call from my AJAX completion callback function. After doing that I noticed that it was now correctly showing a readyState of 4. This meant that somewhere down the line, something was happening to my XHR object causing the readyState to be reset… and possibly resetting my entire XHR object!

Sure enough, I was indeed correct! The problem was that I was trying to directly access my XHR object from within a jQuery animation callback which obviously uses timers. Now, here is where I speculate because the problem only happens in Firefox, but I’m guessing that the XHR object was somehow being reset or altered after some time… very likely an internal browser cache system that was purging my XHR object. My solution was to simply copy the responseText to a variable before entering in to any timer based jQuery calls (essentially, I assigned the responseText to a variable as the first call from my completion callback function). Then, from within my jQuery animation callback I simply referred to the variable I created which had a copy of the responseText. No more random blank responseTexts!