Everybody loves getting something for nothing. But I bet you never realized how much great software Microsoft gives away for free. And when I say free, I don't mean a free 60-day trial. Here are some of the highlights.
AntiVirus:
Microsoft Security Essentials is not only a free antivirus program, but it is the best antivirus program period. I like it more than any other antivirus program, free or otherwise.
Compilers:
Microsoft Visual Studio Express Edition is a completely free version of their flagship compiler. You can't compile every type of Windows program with this version, some of the more esoteric areas of Windows (like Office development) aren't included. But for general use it's pretty full featured.
The Windows Driver Kit is definitely not the most downloaded file from Microsoft. It is intended for developers writing device drivers for Windows. But it does include a C/C++ compiler which can compile more than just kernel code. Visual Studio Express is going to be a better all-around choice, but between the two of these I'm sure you could compile most any program.
Operating Systems:
That's right, Microsoft gives away free versions of Windows. The first I've talked about before, Windows PE. The download is called WAIK, inside of which is WinPE and all the tools and instructions necessary to create a WinPE CD. Whereas WinPE won't make a great general-use operating system, it can run a lot of Windows programs and is a great platform for diagnostics and maintenance. Let's say you run Ubuntu on your system and there is a new BIOS you need to update your system with, but the update program only runs under Windows - how do you install the update? Simple, you boot your system temporarily to WinPE and install the update.
Hyper-V Server 2008 R2 is another completely free version of Windows. This is the "core" version of Windows meaning it doesn't have a graphical Explorer like other Windows. But it is a full-blown copy of Windows.
Whereas Virtual PC 2007 isn't technically an operating system, it is a PC emulator for Windows. This means you can run any operating system virtually on Windows; DOS, Windows, Linux, OS/2, Mac, etc.
Office:
Microsoft Mathematics is a fairly powerful mathematics package. Think of it as a graphing calculator on your computer. Great for students, engineers, scientists, etc.
The Excel, Word, and PowerPoint viewers allow you to view and print Office documents without having to buy and install Microsoft Office. But unfortunately you cannot create or edit documents. But if all you need is to view documents, then these are perfect.
There you have it, 10 free programs from Microsoft which are all very useful.
Showing posts with label Windows. Show all posts
Showing posts with label Windows. Show all posts
Wednesday, June 29, 2011
Tuesday, June 28, 2011
Registry fragmentation
Most people know that fragmentation slows down a computer so you occasionally need to run a defragmenter. But did you know that the Windows registry can become fragmented in two different ways, and there are very few programs to defragment either type?
First, in case you are not familiar with the term fragmentation, basically the data is stored in different locations or fragments. It would be as if your pants were in your closet, your shirts were in the closet in another bedroom, your shoes were at the house across the street, etc. Because your clothes are in different locations it will take you longer to get dressed. In the same way, when computer data is fragmented it slows your computer down.
As I said, the Windows registry can be fragmented in two different ways. The first is the registry files can be fragmented just like any other file stored on the hard drive. Unlike other files on disk, registry files cannot be defragmented via normal means because the files are "locked" while Windows is running. The most common way to defragment the registry hives is to use SysInternal's (a.k.a. Microsoft) program PageDefrag.
The other type of fragmentation requires an understanding of the internal structure of the Windows registry hives. As I blogged about recently the Windows registry is a type of database. Data is constantly being written to, read from, and deleted from the registry. The way the registry is designed, when data is deleted the registry hive does not become smaller. Instead Windows tries to reuse that space in the future, but this ultimately will lead to fragmentation. A key point here to realize is the Windows registry never decreases in size, it only increases in size. Even if you delete most of the data in the registry, the file does not get smaller - and running PageDefrag will do nothing to help with this problem. But there is a way to reclaim this wasted space and defragment the registry at the same time. I recently wrote a program to do just that called HiveDefrag.
If you are like me you are probably wondering if either of these programs make any difference. So I ran some tests to find out. I took a computer that has been used for a long time (the longer a computer has been used the more likely the registry is fragmented and the slower the machine will be). I timed how long from power on until Windows was loaded and idle (i.e. all the startup programs had finished loading). I ran these tests multiple times and averaged the times to get the most accurate results.
I was surprised that PageDefrag had absolutely no effect on the machine's performance whereas HiveDefrag had a noticeable improvement. Yes, 4 seconds may not sound like much, but that was a 13% improvement.
I cannot guarantee every computer will benefit this much, but clearly this shows HiveDefrag can improve your system performance more than PageDefrag can. I would recommend every Windows user run HiveDefrag once a month to keep their system running at peak performance.
First, in case you are not familiar with the term fragmentation, basically the data is stored in different locations or fragments. It would be as if your pants were in your closet, your shirts were in the closet in another bedroom, your shoes were at the house across the street, etc. Because your clothes are in different locations it will take you longer to get dressed. In the same way, when computer data is fragmented it slows your computer down.
As I said, the Windows registry can be fragmented in two different ways. The first is the registry files can be fragmented just like any other file stored on the hard drive. Unlike other files on disk, registry files cannot be defragmented via normal means because the files are "locked" while Windows is running. The most common way to defragment the registry hives is to use SysInternal's (a.k.a. Microsoft) program PageDefrag.
The other type of fragmentation requires an understanding of the internal structure of the Windows registry hives. As I blogged about recently the Windows registry is a type of database. Data is constantly being written to, read from, and deleted from the registry. The way the registry is designed, when data is deleted the registry hive does not become smaller. Instead Windows tries to reuse that space in the future, but this ultimately will lead to fragmentation. A key point here to realize is the Windows registry never decreases in size, it only increases in size. Even if you delete most of the data in the registry, the file does not get smaller - and running PageDefrag will do nothing to help with this problem. But there is a way to reclaim this wasted space and defragment the registry at the same time. I recently wrote a program to do just that called HiveDefrag.
If you are like me you are probably wondering if either of these programs make any difference. So I ran some tests to find out. I took a computer that has been used for a long time (the longer a computer has been used the more likely the registry is fragmented and the slower the machine will be). I timed how long from power on until Windows was loaded and idle (i.e. all the startup programs had finished loading). I ran these tests multiple times and averaged the times to get the most accurate results.
I was surprised that PageDefrag had absolutely no effect on the machine's performance whereas HiveDefrag had a noticeable improvement. Yes, 4 seconds may not sound like much, but that was a 13% improvement.
I cannot guarantee every computer will benefit this much, but clearly this shows HiveDefrag can improve your system performance more than PageDefrag can. I would recommend every Windows user run HiveDefrag once a month to keep their system running at peak performance.
Trojans
Over the past 2 months I've probably repaired or reinstalled a dozen computers belonging to family or friends. Most of these were infected with viruses and/or trojans. I noticed something interesting about how several of the trojans worked. I wanted to share this info so others would be informed and know what to watch out for.
These trojans were redirecting Internet requests without the users knowledge or consent. And I'm sure the reasons for the redirection were malevolent. They used 2 different ways to achieve this redirection.
Hosts file
The "hosts" file is an old seldom used file in Windows that allows users to redirect traffic. The file is located in %WinDir%\system32\drivers\etc. A "clean" hosts file should have one entry as follows: "127.0.0.1 localhost" This means the name "localhost" will resolve to 127.0.0.1. If there are other entries in this file chances are a virus or trojan put them there. You should remove them.
Proxy
The other method I found was by forcing the system to use a proxy. By using a proxy the virus/trojan can redirect traffic as it sees fit. To check your proxy settings go to Control Panel | Internet Settings | Connections, then click on LAN Settings. If the box for Proxy is checked, then a proxy is enabled. You should disable the proxy.
Both of these are clever methods in that they work regardless of the type of browser you're using. Internet Explorer, Firefox, Chrome, etc. would all be redirected without the user even realizing it. And since the hosts file or proxy settings are perfectly valid in certain circumstances, no virus checker would scan for these. So it's up to you to check your own system.
These trojans were redirecting Internet requests without the users knowledge or consent. And I'm sure the reasons for the redirection were malevolent. They used 2 different ways to achieve this redirection.
Hosts file
The "hosts" file is an old seldom used file in Windows that allows users to redirect traffic. The file is located in %WinDir%\system32\drivers\etc. A "clean" hosts file should have one entry as follows: "127.0.0.1 localhost" This means the name "localhost" will resolve to 127.0.0.1. If there are other entries in this file chances are a virus or trojan put them there. You should remove them.
Proxy
The other method I found was by forcing the system to use a proxy. By using a proxy the virus/trojan can redirect traffic as it sees fit. To check your proxy settings go to Control Panel | Internet Settings | Connections, then click on LAN Settings. If the box for Proxy is checked, then a proxy is enabled. You should disable the proxy.
Both of these are clever methods in that they work regardless of the type of browser you're using. Internet Explorer, Firefox, Chrome, etc. would all be redirected without the user even realizing it. And since the hosts file or proxy settings are perfectly valid in certain circumstances, no virus checker would scan for these. So it's up to you to check your own system.
Memory leaks - part 3
Last time I talked about UMDH to find memory leaks in the user-mode heap. This tool probably covers 95% of memory leaks, but there are other ways to leak memory. I wouldn't be surprised even people who are very familiar with UMDH haven't heard of today's utility. It's a tool from Microsoft called LeakDiag.
LeakDiag is like UMDH in that it takes snapshots of a running program and differences them to show you potential leaks. Whereas UMDH only looks at the user-mode heap, LeakDiag looks at the user-mode heap and so much more. LeakDiag can analyze 6 different areas:
You might be asking yourself, if LeakDiag does more than UMDH, why would you ever use UMDH? As I said earlier, most memory leaks occur in the user-mode heap, and UMDH is specifically designed for the user-mode heap so it does a better job at finding and displaying those leaks. So I would recommend using UMDH first, but LeakDiag is a powerful tool to be aware of in case you need it.
LeakDiag is like UMDH in that it takes snapshots of a running program and differences them to show you potential leaks. Whereas UMDH only looks at the user-mode heap, LeakDiag looks at the user-mode heap and so much more. LeakDiag can analyze 6 different areas:
- Virtual memory (VirtualAlloc, VirtualFree, etc.).
- Heap memory (the same as UMDH).
- MPHeap memory (the multi-processor heap).
- COM memory.
- COM private memory.
- C runtime memory.
You might be asking yourself, if LeakDiag does more than UMDH, why would you ever use UMDH? As I said earlier, most memory leaks occur in the user-mode heap, and UMDH is specifically designed for the user-mode heap so it does a better job at finding and displaying those leaks. So I would recommend using UMDH first, but LeakDiag is a powerful tool to be aware of in case you need it.
Memory leaks - part 2
In my last post I introduced UMDH and talked about how it uses snapshots to find memory leaks. In this post I'd like to talk more about how to use it and more importantly tips for improving accuracy.
The output from UMDH is organized with the largest leak at the top and the smallest at the bottom (measured by bytes leaked not the number of times the leak occurred). This is great because if you start at the top and work your way down you'll get the most bang for your buck.
An output entry from UMDH contains several things like the total number of bytes leaked, the number of times the allocator was called without being freed, and most importantly the call stack of the allocation. If you don't have an accurate call stack then check your symbols and make sure you ran the gflags command I mentioned in the last post.
UMDH's greatest attribute, it's ability to capture memory leaks, is also it's greatest weakness. It captures so many memory leaks that you'll get tons of false-positives. This is because Windows is doing stuff under the covers you're not aware of, and this shows up as potential memory leaks in UMDH. My rule of thumb is if the call stack doesn't contain any of my code, I ignore it. Also, just because my code is in the call stack doesn't means it's valid either. So I won't spend too much time investigating a problem. It just takes practice to be able to know what's valid and what's not.
By far the best tip for improving accuracy is to run the program for as long as possible, and separate the time between snapshots as long as possible. What this does is make your memory leaks larger which means they are higher up in the UMDH output file. For example, if your program is a service, take a snapshot Friday before leaving work and take the other snapshot on Monday morning. Also, make sure the program is doing something during this time period. The more it's doing the more likely it is to leak, the larger the leak the easier it is to detect.
The output from UMDH is organized with the largest leak at the top and the smallest at the bottom (measured by bytes leaked not the number of times the leak occurred). This is great because if you start at the top and work your way down you'll get the most bang for your buck.
An output entry from UMDH contains several things like the total number of bytes leaked, the number of times the allocator was called without being freed, and most importantly the call stack of the allocation. If you don't have an accurate call stack then check your symbols and make sure you ran the gflags command I mentioned in the last post.
UMDH's greatest attribute, it's ability to capture memory leaks, is also it's greatest weakness. It captures so many memory leaks that you'll get tons of false-positives. This is because Windows is doing stuff under the covers you're not aware of, and this shows up as potential memory leaks in UMDH. My rule of thumb is if the call stack doesn't contain any of my code, I ignore it. Also, just because my code is in the call stack doesn't means it's valid either. So I won't spend too much time investigating a problem. It just takes practice to be able to know what's valid and what's not.
By far the best tip for improving accuracy is to run the program for as long as possible, and separate the time between snapshots as long as possible. What this does is make your memory leaks larger which means they are higher up in the UMDH output file. For example, if your program is a service, take a snapshot Friday before leaving work and take the other snapshot on Monday morning. Also, make sure the program is doing something during this time period. The more it's doing the more likely it is to leak, the larger the leak the easier it is to detect.
Memory leaks - part 1
I wanted to do a short series on detecting memory leaks. Microsoft has released several great tools for the detection of memory leaks, the first we'll look at is UMDH (user-mode dump heap). I'll start off my saying these posts are probably most beneficial to developers. You'll need the symbols and eventually the source code to find and fix memory leaks. If you don't have these at most you can use UMDH to confirm a given program is leaking memory.
To use UMDH you'll need umdh.exe and gflags.exe, both of which are included with WinDbg in the Debugging Tools for Windows. The first thing you need to do is make sure your symbols are correct and loaded. Create a local symbol folder and download all the symbols for both Microsoft and your code into it. Set the environment variable _NT_SYMBOL_PATH to C:\Symbols (or whatever your path is). Also, set the environmental variable OANOCACHE to 1. This forces COM and OLE to not reuse previously allocated memory which causes false positives with UMDH.
Next we need to enable stack traces. To do this use the command "gflags.exe /I myapp.exe +ust" Replace myapp.exe with the name of the application you're interested in. Do not put the full path to the executable, just the filename. When you're done you can disable stack tracing with "gflags.exe /I myapp.exe -ust"
You're now ready to actually run your app and check for memory leaks. UMDH detects memory leaks by means of snapshots. When you run UMDH it takes a "snapshot" of all the memory allocations of that process. You can then compare two snapshots and it will display the differences. To take a snapshot use the following command: umdh.exe -p:XXXX -f:snapshot1.txt (where XXXX is the process Id of the process to check). After you've taken two snapshots you can compare the two with this command: umdh.exe snapshot1.txt snapshot2.txt -f:results.txt
Next time I'll talk about how to analyze the output. I'll also talk about tips to maximize the accuracy of your results.
To use UMDH you'll need umdh.exe and gflags.exe, both of which are included with WinDbg in the Debugging Tools for Windows. The first thing you need to do is make sure your symbols are correct and loaded. Create a local symbol folder and download all the symbols for both Microsoft and your code into it. Set the environment variable _NT_SYMBOL_PATH to C:\Symbols (or whatever your path is). Also, set the environmental variable OANOCACHE to 1. This forces COM and OLE to not reuse previously allocated memory which causes false positives with UMDH.
Next we need to enable stack traces. To do this use the command "gflags.exe /I myapp.exe +ust" Replace myapp.exe with the name of the application you're interested in. Do not put the full path to the executable, just the filename. When you're done you can disable stack tracing with "gflags.exe /I myapp.exe -ust"
You're now ready to actually run your app and check for memory leaks. UMDH detects memory leaks by means of snapshots. When you run UMDH it takes a "snapshot" of all the memory allocations of that process. You can then compare two snapshots and it will display the differences. To take a snapshot use the following command: umdh.exe -p:XXXX -f:snapshot1.txt (where XXXX is the process Id of the process to check). After you've taken two snapshots you can compare the two with this command: umdh.exe snapshot1.txt snapshot2.txt -f:results.txt
Next time I'll talk about how to analyze the output. I'll also talk about tips to maximize the accuracy of your results.
Thursday, June 23, 2011
Wireless on my desktop?
Time for another good rant. One thing that has long annoyed me about Windows XP is by default the Wireless service is set to automatic. So on my desktop system which does not have a wireless card, there is an extra service running all the time. This seems like a waste to run this service on systems without the hardware. Surely Microsoft could detect wireless hardware and stop the service if none is found.
I totally understand why Microsoft chose to let it run. Many users have laptops, and most laptop users connect wirelessly, and most computer users are not savvy enough to troubleshoot wireless connection issues. But it feels like desktop users are punished to support laptops.
BTW, if you have a desktop and want to correct this, go into Services in Control Panel and set the "Wireless Zero Configuration" to manual or disabled.
I totally understand why Microsoft chose to let it run. Many users have laptops, and most laptop users connect wirelessly, and most computer users are not savvy enough to troubleshoot wireless connection issues. But it feels like desktop users are punished to support laptops.
BTW, if you have a desktop and want to correct this, go into Services in Control Panel and set the "Wireless Zero Configuration" to manual or disabled.
Blue Screen of Death
The "Blue Screen of Death" or BSOD is a dreaded crash of Windows. I remember about 2 years ago I had an epiphany when I suddenly realized exactly what causes a BSOD of death and why Windows can't continue. I would like to share this with you in case you don't realize.
Ultimately it boils down to an unhandled exception; but it's more than that. First, what is an exception? Well as the name implies, it's an exceptional condition that has occurred outside of the expected flow of execution. Take for example the following line of pseudo-code:
x = 6 / 2;
Obviously x equals 3. But what about this:
x = 8 / 0;
What does x equal? The answer is undefined. It doesn't equal anything because you can't divide a number by 0. So how does a computer handle this? Well it can't return a value to x because that would be wrong. Even if it returned a value of 0, there would be nothing to differentiate between this and "x = 0 / 8;" This is where exceptions come in. The computer "raises" an exception telling the program that an unexpected event occurred.
As developers, we can account for exceptions when they occur. We can add special code to our program to "catch" these raised exceptions and recover from them. If however the programmer does not add code to handle exceptions, the exception raises all the way up to the OS which kills the program and reports the error to the user. If you've ever seen Dr. Watson, this is the program in Windows that handles exceptions that the programmer didn't handle.
That explains exceptions, but it still doesn't explain BSOD. Windows is divided into two parts, kernel level and user or application level. Basically everything you see and interact with is user level, and some of the under-the-covers stuff like drivers are kernel level. An unhandled exception in a kernel level program results in a BSOD. So user level is to Dr. Watson as kernel level is to BSOD.
This also explains why if you get a BSOD, 99% of the time the solution to the problem is to find the offending driver and download an updated version and hope the problem was fixed. About the only time this doesn't work is if the BSOD was ultimately caused by a hardware failure.
Ultimately it boils down to an unhandled exception; but it's more than that. First, what is an exception? Well as the name implies, it's an exceptional condition that has occurred outside of the expected flow of execution. Take for example the following line of pseudo-code:
x = 6 / 2;
Obviously x equals 3. But what about this:
x = 8 / 0;
What does x equal? The answer is undefined. It doesn't equal anything because you can't divide a number by 0. So how does a computer handle this? Well it can't return a value to x because that would be wrong. Even if it returned a value of 0, there would be nothing to differentiate between this and "x = 0 / 8;" This is where exceptions come in. The computer "raises" an exception telling the program that an unexpected event occurred.
As developers, we can account for exceptions when they occur. We can add special code to our program to "catch" these raised exceptions and recover from them. If however the programmer does not add code to handle exceptions, the exception raises all the way up to the OS which kills the program and reports the error to the user. If you've ever seen Dr. Watson, this is the program in Windows that handles exceptions that the programmer didn't handle.
That explains exceptions, but it still doesn't explain BSOD. Windows is divided into two parts, kernel level and user or application level. Basically everything you see and interact with is user level, and some of the under-the-covers stuff like drivers are kernel level. An unhandled exception in a kernel level program results in a BSOD. So user level is to Dr. Watson as kernel level is to BSOD.
This also explains why if you get a BSOD, 99% of the time the solution to the problem is to find the offending driver and download an updated version and hope the problem was fixed. About the only time this doesn't work is if the BSOD was ultimately caused by a hardware failure.
Windows Explorer tip
I wanted to share a little tip I learned many years ago - how to unload Windows Explorer without exiting Windows. This might seem like an odd thing to want to do, but over the years I've found reasons why. Maybe Windows Explorer has locked a file that I want to delete, or maybe Explorer has a USB flash drive locked and won't let me eject it (this seems to happen a lot), or maybe there's a serious memory leak in Explorer and you need the process to free all that memory. As a developer I've found reasons why I need to take Explorer out of the picture when debugging a problem in my code. So there are reasons to want to unload Windows Explorer. But typically when you exit Windows Explorer, Windows itself exits.
This tip is pretty easy. You need to bring up the "Shut Down Windows" dialog. You can do this by clicking Start then Shut Down. You can also click on your desktop then press Alt+F4. Once you see the "Shut Down Windows" dialog press and hold Ctrl+Shift+Alt then click the cancel button. Windows Explorer will disappear but Windows will not exit.
After you're done you can reload Explorer by pressing Ctrl+Shift+Esc at the same time. This will bring up Task Manager. From Task Manager you can run a new task of "explorer.exe" This will reload Windows Explorer and you can resume where you left off.
This tip is pretty easy. You need to bring up the "Shut Down Windows" dialog. You can do this by clicking Start then Shut Down. You can also click on your desktop then press Alt+F4. Once you see the "Shut Down Windows" dialog press and hold Ctrl+Shift+Alt then click the cancel button. Windows Explorer will disappear but Windows will not exit.
After you're done you can reload Explorer by pressing Ctrl+Shift+Esc at the same time. This will bring up Task Manager. From Task Manager you can run a new task of "explorer.exe" This will reload Windows Explorer and you can resume where you left off.
Wednesday, June 22, 2011
The case of the missing driver - part 3
Yesterday we learned how to identify unknown hardware. In today's post we'll talk about finding and installing the driver for that hardware. Let's look more closely at a hardware identification string we found.
PCI\VEN_8086&DEV_27D0&SUBSYS_00000000&REV_01
This string tells me 5 things. In order from left to right they are:
Again, hardware identification strings vary greatly, but most of them look like the above. Let's focus on the vender number. Surf on over to pcidatabase. Enter your vendor number into the "vendor" field and click search. This will tell you who the manufacture is of that hardware. In my case 8086 is Intel. Click on the vendors name and it will bring up a list of known device identifiers. Search for your device identifier in this list. I'll tell you right now this list is not complete, so you may not find it. But if you do find it, it will give you some info about the device such as a friendly name and if you're lucky a link to the driver.
Assuming you still need the driver, you have the manufacture's name and hopefully the device's friendly name. You can now visit that manufactures web page and download the driver.
If after all this you're still unable to find the correct driver, you can try putting the raw hardware identification string into a Google and see what you get. A lot of times you get lucky, but this is no guarantee.
There you have it, how to identify hardware and find the correct driver. Once I learned this process I've never had hardware I couldn't find a driver for. Hopefully you enjoy as much success as I have.
PCI\VEN_8086&DEV_27D0&SUBSYS_00000000&REV_01
This string tells me 5 things. In order from left to right they are:
- The hardware is located on the PCI bus.
- The vendor/manufacture number is 8086.
- The device identifier is 27D0.
- The subsystem identifier is 00000000.
- The revision number is 01.
Again, hardware identification strings vary greatly, but most of them look like the above. Let's focus on the vender number. Surf on over to pcidatabase. Enter your vendor number into the "vendor" field and click search. This will tell you who the manufacture is of that hardware. In my case 8086 is Intel. Click on the vendors name and it will bring up a list of known device identifiers. Search for your device identifier in this list. I'll tell you right now this list is not complete, so you may not find it. But if you do find it, it will give you some info about the device such as a friendly name and if you're lucky a link to the driver.
Assuming you still need the driver, you have the manufacture's name and hopefully the device's friendly name. You can now visit that manufactures web page and download the driver.
If after all this you're still unable to find the correct driver, you can try putting the raw hardware identification string into a Google and see what you get. A lot of times you get lucky, but this is no guarantee.
There you have it, how to identify hardware and find the correct driver. Once I learned this process I've never had hardware I couldn't find a driver for. Hopefully you enjoy as much success as I have.
The case of the missing driver - part 2
Continuing the case of the missing driver, let's talk about identification. In order to find the driver for the hardware in question you need to know exactly what the hardware is. And no, I'm not talking about opening up the case and having a look - although under extreme circumstances that might become necessary.
When we talk about identification what we're looking for is the "hardware identification string." This is not a user-friendly string like "Intel GMA 4500MHD video card." It's a long string of hex numbers and letters that uniquely identify the hardware. All hardware identification strings are in the form of <Bus>\<Id>. The "bus" is one of 15 hardware busses in a modern computer. Those 15 busses are; ACPI, ACPI_HAL, Display, FDC, HID, HTREE, IDE, ISAPNP, PCI, PCIIDE, Root, Storage, SW, USB, and USBSTOR. The "id" part of the string varies greatly depending on the type of bus. It can be short like "PNP0000" or long like "VEN_8086&DEV_27D0&SUBSYS_00000000&REV_01."
Now that we know what the hardware identification string looks like, we need to find it for our unknown hardware. I'll give you three ways.
First is a program I found years ago called PCITree. This program enumerates PCI hardware and provides the identification information for each device. I actually don't recommend this method unless you want to play with PCITree. This program only works on PCI devices which is only one of the 15 busses. Plus there are other ways of getting the data without having to install a program.
The second method is the good old registry. Fire up regedit and head over to HKLM\System\CurrentControlSet\Enum. You'll see 15 keys for the corresponding busses, under each key are keys for the hardware on that bus. The unknown hardware will be in this area. To make it easier you can search. So if Windows calls the unknown device an "SM Bus Controller" than you can search for that term.
The final method is also the easiest and probably the one you'll want to use. You can get the info in question in Device Manager. Select the unknown device and right-click and choose properties. Click on the details tab then change the combo box to "Device Instance Id." The information shown in the list control is the hardware identification string. Unfortunately you can't copy that text into the clipboard, that's the only problem with the Device Manager method.
Now that we've identified our hardware, tomorrow I'll talk about how we find and install the driver for this hardware.
When we talk about identification what we're looking for is the "hardware identification string." This is not a user-friendly string like "Intel GMA 4500MHD video card." It's a long string of hex numbers and letters that uniquely identify the hardware. All hardware identification strings are in the form of <Bus>\<Id>. The "bus" is one of 15 hardware busses in a modern computer. Those 15 busses are; ACPI, ACPI_HAL, Display, FDC, HID, HTREE, IDE, ISAPNP, PCI, PCIIDE, Root, Storage, SW, USB, and USBSTOR. The "id" part of the string varies greatly depending on the type of bus. It can be short like "PNP0000" or long like "VEN_8086&DEV_27D0&SUBSYS_00000000&REV_01."
Now that we know what the hardware identification string looks like, we need to find it for our unknown hardware. I'll give you three ways.
First is a program I found years ago called PCITree. This program enumerates PCI hardware and provides the identification information for each device. I actually don't recommend this method unless you want to play with PCITree. This program only works on PCI devices which is only one of the 15 busses. Plus there are other ways of getting the data without having to install a program.
The second method is the good old registry. Fire up regedit and head over to HKLM\System\CurrentControlSet\Enum. You'll see 15 keys for the corresponding busses, under each key are keys for the hardware on that bus. The unknown hardware will be in this area. To make it easier you can search. So if Windows calls the unknown device an "SM Bus Controller" than you can search for that term.
The final method is also the easiest and probably the one you'll want to use. You can get the info in question in Device Manager. Select the unknown device and right-click and choose properties. Click on the details tab then change the combo box to "Device Instance Id." The information shown in the list control is the hardware identification string. Unfortunately you can't copy that text into the clipboard, that's the only problem with the Device Manager method.
Now that we've identified our hardware, tomorrow I'll talk about how we find and install the driver for this hardware.
The case of the missing driver
Have you ever had a computer with a missing driver, and no matter how hard you look you can't find the driver. Heck, you may not even know what the hardware device is. A bad or missing driver will show up in Device Manager like this:
In this case I've got two missing drivers. The first, "Multimedia Audio Controller" is fairly easy, that's a missing sound card driver. But what is an "SM Bus Controller?" Where do I look for that driver? I've even seen "Unknown PCI Device" before. How do you look for a driver for a device that you don't even know what it is?
If the machine has a major manufacture (Dell, HP, etc.) then you've probably been to their page to download drivers. But what if the machine isn't from a major manufacture, of even if it is what if you can't find the driver, then what? Microsoft Windows update can be a useful resource. Their database contains a lot of drivers and will automatically detect and install. However, their system has one fundamental flaw. Microsoft charges vendors a fee to validate and host drivers for them. As I understand it, this fee is fairly significant too. As a result, many vendors drivers are not available on Windows Update.
If you Google things like "driver downloads" you'll probably find several web sites that have large collections of drivers. All these sites that I've found are very sketchy. At a minimum they all require you to register and I hate giving out my information - just another way to get spammed. Many of them require you to download and install a program of theirs which scans your system and reports missing drivers. I don't like installing questionable programs, who knows all what it's installing. And what's worst, some of these sites if you do go through all these hoops and they do contain your missing driver, they make you pay a monthly fee to be able to download the driver in question. My recommendation is unless a site allows you to download a driver without signing up or downloading a program to avoid these sites altogether.
But that brings up back to the original problem, how do we find the driver for our hardware? When I continue this series tomorrow I'll talk about identifying the hardware in question.
In this case I've got two missing drivers. The first, "Multimedia Audio Controller" is fairly easy, that's a missing sound card driver. But what is an "SM Bus Controller?" Where do I look for that driver? I've even seen "Unknown PCI Device" before. How do you look for a driver for a device that you don't even know what it is?
If the machine has a major manufacture (Dell, HP, etc.) then you've probably been to their page to download drivers. But what if the machine isn't from a major manufacture, of even if it is what if you can't find the driver, then what? Microsoft Windows update can be a useful resource. Their database contains a lot of drivers and will automatically detect and install. However, their system has one fundamental flaw. Microsoft charges vendors a fee to validate and host drivers for them. As I understand it, this fee is fairly significant too. As a result, many vendors drivers are not available on Windows Update.
If you Google things like "driver downloads" you'll probably find several web sites that have large collections of drivers. All these sites that I've found are very sketchy. At a minimum they all require you to register and I hate giving out my information - just another way to get spammed. Many of them require you to download and install a program of theirs which scans your system and reports missing drivers. I don't like installing questionable programs, who knows all what it's installing. And what's worst, some of these sites if you do go through all these hoops and they do contain your missing driver, they make you pay a monthly fee to be able to download the driver in question. My recommendation is unless a site allows you to download a driver without signing up or downloading a program to avoid these sites altogether.
But that brings up back to the original problem, how do we find the driver for our hardware? When I continue this series tomorrow I'll talk about identifying the hardware in question.
Windows Image Viewer
Ok, time for another rant. I would like to complain about the default Windows image viewer called Windows Image Viewer. This program has been around since at least XP (possibly earlier), but this program has some glaring flaws in it and it's surprising nothing has been done about them yet. And keep in mind, this program is the default image viewer on Windows, so unless the user specifically selects a different viewer they will run into the following problems.
Before I talk about the problems, I first want to talk about Exchangeable image file format (EXIF). EXIF is an optional structure found in JPGs and some other image files which contains information about the picture itself. For example, the EXIF contains the make and model of the camera as well as all the camera settings that were used to take the picture. In my opinion one of the most useful fields in EXIF is called "orientation" and it records how the camera was held when the picture was taken. Not all cameras save this EXIF info, I have one camera that does and one that doesn't. But I think it is becoming more and more common. Now onto the flaws...
My first gripe with Windows Image Viewer is it does not read the EXIF field. This isn't a heinous crime, many image viewers do not read this field. But after you've used an EXIF-aware program which automatically displays images in their correct orientation, it's hard to use a program that does not.
My second complaint is Windows Image Viewer modifies and saves your images without telling you. Since Windows Image Viewer does not auto-rotate the image, you have to use the controls in that program to rotate the image for viewing. But what Windows Image Viewer doesn't tell you is the act of rotated an image saves the image in the new rotation. The next time you open that image it was saved in the new orientation. There are two things bad about this. First, you shouldn't save any file without the users knowledge or consent. After all this program is a "viewer" implying it does not modify files. Secondly, because JPGs are lossy compression every time a JPG is saved it loses data and slowly degrades the image.
And the last most annoying problem with Windows Image Viewer is when it silently saves images, it corrupts them! On Windows XP some of the fields in the EXIF (like orientation) are removed and other fields are saved with garbage characters in them. On Vista and Win7 no fields are removed or corrupted, however if the picture is rotated the orientation field is not updated. Regardless of platform, the next time you open the image in an EXIF-aware program the orientation is now wrong.
Windows Image Viewer has had these problems for a long time, I just can't believe Microsoft hasn't addressed them.
Before I talk about the problems, I first want to talk about Exchangeable image file format (EXIF). EXIF is an optional structure found in JPGs and some other image files which contains information about the picture itself. For example, the EXIF contains the make and model of the camera as well as all the camera settings that were used to take the picture. In my opinion one of the most useful fields in EXIF is called "orientation" and it records how the camera was held when the picture was taken. Not all cameras save this EXIF info, I have one camera that does and one that doesn't. But I think it is becoming more and more common. Now onto the flaws...
My first gripe with Windows Image Viewer is it does not read the EXIF field. This isn't a heinous crime, many image viewers do not read this field. But after you've used an EXIF-aware program which automatically displays images in their correct orientation, it's hard to use a program that does not.
My second complaint is Windows Image Viewer modifies and saves your images without telling you. Since Windows Image Viewer does not auto-rotate the image, you have to use the controls in that program to rotate the image for viewing. But what Windows Image Viewer doesn't tell you is the act of rotated an image saves the image in the new rotation. The next time you open that image it was saved in the new orientation. There are two things bad about this. First, you shouldn't save any file without the users knowledge or consent. After all this program is a "viewer" implying it does not modify files. Secondly, because JPGs are lossy compression every time a JPG is saved it loses data and slowly degrades the image.
And the last most annoying problem with Windows Image Viewer is when it silently saves images, it corrupts them! On Windows XP some of the fields in the EXIF (like orientation) are removed and other fields are saved with garbage characters in them. On Vista and Win7 no fields are removed or corrupted, however if the picture is rotated the orientation field is not updated. Regardless of platform, the next time you open the image in an EXIF-aware program the orientation is now wrong.
Windows Image Viewer has had these problems for a long time, I just can't believe Microsoft hasn't addressed them.
Tuesday, June 21, 2011
Power Management and USB keyboards
I discovered recently Power Management is a complex interaction between hardware and software, and there's a very common setup in which this interaction fails. The problem centers around the sleep state, sometimes called standby (because Microsoft incorrectly used this term in place of "sleep"), or technically speaking S3. When I upgraded my home computer from Win2000 to WinXP I noticed a difference in the sleep state. The monitor would still go black and the computer would appear to be asleep, but the fans on the power supply were still running. This was an annoyance but it literally would be years before I discovered what is going on here.
If you have a USB keyboard which is configured to wake the machine from sleep then the USB bus must be powered. Makes sense, the keyboard cannot wake the machine if there's no power to the keyboard. Here's where the hardware/software interaction comes into play. The hardware (motherboard and power supply) must be able to trickle power to the USB bus. Windows checks if the hardware supports this and if so the machine enters full sleep (S3), if not the machine enters a slightly reduced power state (S1).
That's how it's supposed to work, but it doesn't always happen that way. Windows XP and 2003 ignore what the hardware claims to support and always assumes the hardware does not support S3. This means by default XP and 2003 with a USB keyboard will never enter a sleep state. How much wasted power are we talking about? Using a Kill-A-Watt I tested my home system (Core 2 Quad). Windows sitting idle the machine uses 86 watts of power. In sleep (S3) the machine uses 6 watts. And in S1 the machine still uses 86 watts. A lot of people like to leave there machines on 24/7. Let's say the machine is in use 8 hours a day, which means for 16 hours the machine should be sleep but instead it's using 80 watts extra. This equals 467 kWhr per machine per year, or $51 per machine per year (assuming 11 cents per kWhr).
There are several solutions to this problem.
1) You can disable the keyboard wake capability. In Device Manager (run devmgmt.msc) find your keyboard. Right-click and select properties, then select the Power Management tab. Uncheck “Allow this device to bring the computer out of standby.” Now your computer should go completely into standby mode, but you will have to use the power button on the computer to wake it back up.
2) You can set the USBBIOSx registry key detailed in KB841858. This key forces XP and 2003 to always assume your hardware supports trickle power for USB. This will allow your computer to enter full sleep and still use the keyboard to wake the machine.
Windows XP is still the most common OS, and USB keyboards are very common - so we're talking about a lot of machines in this world that are wasting a ton of electricity. Is your machine one of them?
If you have a USB keyboard which is configured to wake the machine from sleep then the USB bus must be powered. Makes sense, the keyboard cannot wake the machine if there's no power to the keyboard. Here's where the hardware/software interaction comes into play. The hardware (motherboard and power supply) must be able to trickle power to the USB bus. Windows checks if the hardware supports this and if so the machine enters full sleep (S3), if not the machine enters a slightly reduced power state (S1).
That's how it's supposed to work, but it doesn't always happen that way. Windows XP and 2003 ignore what the hardware claims to support and always assumes the hardware does not support S3. This means by default XP and 2003 with a USB keyboard will never enter a sleep state. How much wasted power are we talking about? Using a Kill-A-Watt I tested my home system (Core 2 Quad). Windows sitting idle the machine uses 86 watts of power. In sleep (S3) the machine uses 6 watts. And in S1 the machine still uses 86 watts. A lot of people like to leave there machines on 24/7. Let's say the machine is in use 8 hours a day, which means for 16 hours the machine should be sleep but instead it's using 80 watts extra. This equals 467 kWhr per machine per year, or $51 per machine per year (assuming 11 cents per kWhr).
There are several solutions to this problem.
1) You can disable the keyboard wake capability. In Device Manager (run devmgmt.msc) find your keyboard. Right-click and select properties, then select the Power Management tab. Uncheck “Allow this device to bring the computer out of standby.” Now your computer should go completely into standby mode, but you will have to use the power button on the computer to wake it back up.
2) You can set the USBBIOSx registry key detailed in KB841858. This key forces XP and 2003 to always assume your hardware supports trickle power for USB. This will allow your computer to enter full sleep and still use the keyboard to wake the machine.
Windows XP is still the most common OS, and USB keyboards are very common - so we're talking about a lot of machines in this world that are wasting a ton of electricity. Is your machine one of them?
Windows annoyances
There's nothing quite like ranting about something, I think it's even therapeutic. And what better topic for me to rant about than Microsoft Windows. Every time a new version of Windows comes out I install it eager to see what new and "cool" things Microsoft added. But sadly I'm also looking for what changes and annoyances Microsoft added as well. One of those annoying changes is full row select in Windows Explorer. Starting in Windows Vista if you change Explorer to "Detail" view it uses full row select, meaning you can select an item by clicking on the same row at the far right of the screen. In all previous versions of Windows you had to click on the name itself to select the item.
Here is an image of Vista with full row select:
And here is XP with the previous behavior:
This simple little change had a very profound impact on the speed and usability of Windows for me. I use the mouse a lot to select files, and when full row select is enabled you cannot click in the white space and drag a rectangle around multiple files to select them because of the simple fact there is no longer white space. Eventually I found a way to restore the original behavior by changing a registry key (surprise surprise). Suddenly Vista was usable again.
Fast forward a couple of years to Windows 7. That same registry key no longer works. If you google this people have tried tons of different things, and failed. Just the other day I found a post by a Microsoft employee on their support forum which confirmed my fears, Microsoft decided to eliminate the ability to control this and now always forces full row select to be enabled in Windows 7.
As if usability wasn't a problem enough, the reasoning behind full row select just pours salt in the wound. Microsoft added full row select to detail view to help touch-screen tablet users. I guess selecting small objects like files is difficult when using a fat inaccurate pointing device like your finger. But touch-screen tablet users are what, like 1% of the market at most. So to support less than 1% of the market Microsoft makes a change which inconveniences the rest of us. I'm all for adding a feature to support this, but make it user selectable.
Here is an image of Vista with full row select:
And here is XP with the previous behavior:
This simple little change had a very profound impact on the speed and usability of Windows for me. I use the mouse a lot to select files, and when full row select is enabled you cannot click in the white space and drag a rectangle around multiple files to select them because of the simple fact there is no longer white space. Eventually I found a way to restore the original behavior by changing a registry key (surprise surprise). Suddenly Vista was usable again.
Fast forward a couple of years to Windows 7. That same registry key no longer works. If you google this people have tried tons of different things, and failed. Just the other day I found a post by a Microsoft employee on their support forum which confirmed my fears, Microsoft decided to eliminate the ability to control this and now always forces full row select to be enabled in Windows 7.
As if usability wasn't a problem enough, the reasoning behind full row select just pours salt in the wound. Microsoft added full row select to detail view to help touch-screen tablet users. I guess selecting small objects like files is difficult when using a fat inaccurate pointing device like your finger. But touch-screen tablet users are what, like 1% of the market at most. So to support less than 1% of the market Microsoft makes a change which inconveniences the rest of us. I'm all for adding a feature to support this, but make it user selectable.
Monday, June 20, 2011
WinPE CD
Microsoft Windows PE is, in my opinion, one of the most powerful and coolest new technologies in the last 5 years, and it's also one of the most under-hyped and under-utilized new technologies. A decade or more ago most serious computer users had their own special DOS boot disks (I still have them in my office). Few machines these days come with floppy drives, plus what you can effectively do with 1.44MB worth of space is very limited. That's where WinPE comes in. It's the new diagnostic platform of choice. I believe everyone should create and keep a WinPE CD with them. Keep it in your office, or if you're on the go a lot, keep it in your laptop bag. You'll never know when you'll need it, but when you do need it you'll be glad you have it. So now is the time to create one.
Unfortunately, creating a WinPE bootable CD (or USB drive) isn't a simple straightforward process. Here are the steps you'll need to go through:
Download and install WAIK from Microsoft.
From the start menu run the newly created WAIK Command Prompt.
Run "copype.cmd x86 c:\winpe"
Run "copy c:\winpe\winpe.wim c:\winpe\ISO\sources\boot.wim"
Run "oscdimg -n -bC:\winpe\etfsboot.com C:\winpe\ISO C:\winpe\winpe.iso"
This will create your ISO image (C:\winpe\winpe.iso) which you can burn onto a CD. If you wish to customize WinPE, between steps 4 and 5 you can copy files and programs into the C:\winpe\ISO folder. After creating your CD I suggest you boot it at least once. To make sure it worked, but also to make sure you understand what WinPE looks like and how to use it. WinPE's interface is a command prompt, so you'll need to know basic commands in order to get work done.
What can you do from WinPE? A better question is what can't you do from WinPE. You can run diagnostics on your system if you're having problems. You can scan for viruses, trojans, or rootkits without fear of further infection. You can create and restore images of your system. You can defrag your hard drive without any locked files. The sky's the limit - so create your WinPE CD now and see what ideas you come up with.
Unfortunately, creating a WinPE bootable CD (or USB drive) isn't a simple straightforward process. Here are the steps you'll need to go through:
Download and install WAIK from Microsoft.
From the start menu run the newly created WAIK Command Prompt.
Run "copype.cmd x86 c:\winpe"
Run "copy c:\winpe\winpe.wim c:\winpe\ISO\sources\boot.wim"
Run "oscdimg -n -bC:\winpe\etfsboot.com C:\winpe\ISO C:\winpe\winpe.iso"
This will create your ISO image (C:\winpe\winpe.iso) which you can burn onto a CD. If you wish to customize WinPE, between steps 4 and 5 you can copy files and programs into the C:\winpe\ISO folder. After creating your CD I suggest you boot it at least once. To make sure it worked, but also to make sure you understand what WinPE looks like and how to use it. WinPE's interface is a command prompt, so you'll need to know basic commands in order to get work done.
What can you do from WinPE? A better question is what can't you do from WinPE. You can run diagnostics on your system if you're having problems. You can scan for viruses, trojans, or rootkits without fear of further infection. You can create and restore images of your system. You can defrag your hard drive without any locked files. The sky's the limit - so create your WinPE CD now and see what ideas you come up with.
Subscribe to:
Posts (Atom)