At some point I got sick of burning coasters and switched to doing Windows trial installs from USB by using the Windows USB/DVD download tool to “burn” ISOs to bootable flash media. I quickly realized that USB sticks were error-prone, but SD and Micro-SD cards have some magic error correction that makes them reliable. The big problem is, they don’t take a label. And there’s no easy way to tell by looking at the root what version of Windows it is. Sometimes even running the installer doesn’t tell you immediately. I should stick a readme file in there, but I don’t.
Fortunately, there is a way to tell exactly what installer it is. From an administrative command prompt, you run this command against the drive letter where the SD card mounted:
And you get something like…
Deployment Image Servicing and Management tool
Details for image : H:\sources\install.wim
Index : 1
Name : Windows 10 Pro Technical Preview
Description : Windows 10 Pro Technical Preview
Size : 13,234,784,840 bytes
Architecture : x64
Hal : acpiapic
Version : 10.0.10074
ServicePack Build : 0
ServicePack Level : 0
Edition : Professional
Installation : Client
ProductType : WinNT
ProductSuite : Terminal Server
System Root : WINDOWS
Directories : 20512
Files : 101176
Created : 4/25/2015 - 12:04:04 AM
Modified : 4/25/2015 - 12:04:39 AM
The operation completed successfully.
What more could you ask for?
When creating a Windows Forms application in Visual Studio and implementing drag-and-drop you may encounter this exception during debugging if you drag outside your own application, even though the drag and drop operations complete successfully inside your application.
This may not be a bug, or even an error! Things to try:
- Run the application executable directly from the debug folder, not in Visual Studio debug mode.
- Run in VS debug mode with your application directly over a window that can accept its drag content type. Perform the drag directly from your application to the valid drop zone on the other application, passing over no other applications (including the desktop) or invalid drop zones. For example, if you are using DataObject.SetText, place your application directly over the text area of a text editor that accepts dragging, e.g. WordPad.
In those two conditions, you probably won’t see the exception thrown and the drag-and-drop will succeed.
I think what’s happening here is that Visual Studio is being a little too aggressive in watching the Windows event messaging system. Because of the way dragging works, these “first chance” COM exceptions will occur as the dragging mouse passes over targets that cannot accept the content stored in the DataObject. If they have any drag-drop awareness, they will attempt a COM native “get” operation on the FORMATETC structure created when you initiated the drag in your application (you used the DataObject wrapper and injected it with DoDragDrop, but this is what you did in effect). If the format doesn’t match any of the formats the dragged-over applications (including Windows Explorer, a.k.a. the desktop) accept, this exception is thrown. It is then, typically, handled either by that application or Windows itself, for example by switching to the “um, not so much” cursor (circle with line through it). Running outside of debug mode, or between two application that agree on format, it “just works” (dropping successfully in places it can, blocking the drop in places it can’t). In debug mode, VS is telling you, “hey, look, an exception, you could handle this if you wanted to,” but in most cases you’ll just let the OS or other applications handle it.
Bottom line: don’t sweat this one too much if your application runs okay outside the debugger and in the controlled debugging conditions described above.
Here’s an article that is the closest thing I could find to an official explanation.
Just had a scary one… After setting up Windows Server 2012 R2 to back up all its Hyper-V VMs through the host’s nightly Windows Backup I found that only one of the three Windows Server 2008 R2 VM clients was being backed up. The other two were failing, one with a disk CRC error, the other for no listed reason. Based on some searching, I suspected a problem with disk ID clashes–all the VMs were from the same template .vhdx file, so they all had the same “unique” ID. Oops. This is actually supposed to be handled okay by the current version of Windows Backup on a Hyper-V host, but I figured I’d eliminate it as a potential issue anyway. So, I had run DISKPART UNIQUEID DISK to reset all the Ids on all the partitions (virtual disks) in the pool of VMs to unique values. This morning I checked the logs and saw the backups up the two VMs again failed.
Next I tried a chkdsk on all the volumes on the affected VMs. However, after scheduling the chkdsks and rebooting the VMs I got the dreaded black screen of “no boot device can be found.” This happened on both the VMs I had tried (the third I hadn’t attempted to reboot yet), for which I, of course, had no backup. Oh no. Unlike Windows 7, Windows Server 2008 R2 lacks any automatic repair tool. Fortunately, a quick Google search turned up a Tom’s Hardware thread that indicated that the “repair” command prompt available from the original install DVD would allow the repair of the boot record with this command:
That command actually will scan all the mounted partitions and offer to add any Windows installations to the boot loader. In my case, there was only one installation offered per VM and by selecting it I was back in business. The scheduled disk checks even kicked in and now all the machines are up and running. Whether this actually fixes the backup issue we’ll see tomorrow…
[Updated for 2017]
This post originally was about FCIV, which is no longer the right choice. Today we use CertUtil:
certUtil -hashfile pathToFileToCheck [HashAlgorithm]
HashAlgorithm choices: MD2 MD4 MD5 SHA1 SHA256 SHA384 SHA512
Because I keep forgetting…
fciv Filename.iso -both
Resides in C:\Windows\System32 and requires an elevated command prompt (or the Visual Studio Command Prompt).
If you don’t have fciv, it can be downloaded here:
I struggled a long time trying to get remote shutdown via the command line working in a Windows 7/Vista environment (specifically a Windows 7 machine attempting to remotely reboot or shutdown a Windows Vista machine). The shutdown.exe command line utility that worked fine under XP/2003 just didn’t work, usually giving an “Error 5,” which I gather is some kind of permissions issue.
As usual with one of these annoying, should-be-simple technical problems with Windows, SysInternals already has it all worked out for you. Their PsShutdown utility “just works.” In my case the magic command line was:
psshutdown \\ComputerName -u UserName(OnRemoteMachine) -p Password(OnRemoteMachine) -s
Admit it, sometimes you uninstall hardware without removing the driver first. Sometimes the hardware just dies and Windows makes it “go away.” The problem is, the driver and configuration are still there, and if you were using the default Microsoft drivers, there’s no visible way to uninstall those.
Here’s a workaround:
- Obtain an administrative command prompt (Start|All Programs|Accessories, right click on Command Prompt and click Run as Administrator)
- At the command prompt, type or paste:
- Then type:
- This will pop up a normal-looking Device Manager, in the menu of which click View|Show Hidden Devices
- Expand the relevant part of the tree and (with care) uninstall away!
Under IIS6, you used to be able to run this .vbs script at the command line to list all the running app pools and view their Proc Ids:
That script isn’t shipped with IIS7, and it wouldn’t run anyway without modification and the “IIS6 Management Compatibility” installed. Instead, you can use appcmd.exe to obtain similar information using this command line:
C:\Windows\System32\inetsrv\appcmd list wp
Note, you will need to run the command line as administrator and be in one of the directories where appcmd.exe esists. I used the 32-bit example here, but on my 64-bit Windows 7 and Server 2008 machines, appcmd.exe exists in both of these directories and produces the same results:
Alt-F4 gives you the full local shutdown menu.
Of course you won’t be able to bring the machine back from most of these states remotely unless you have wake-on-LAN, remote power cycle, etc.
This comes up more often than we’d like. And while I’d love Microsoft to fix this and allow unlimited Remote Desktop connections to a server, it doesn’t seem like it’s going to happen. If you get the dreaded “The terminal server has exceeded the maximum number of allowed connections” message, here’s how you can force connect and boot someone else:
Mstsc /v:192.168.0.x /admin /F
It used to be /console instead of /admin, but that went away in XP SP3.
But let’s be clear on what the real fix here is: Microsoft needs to release the 2-user limit on administrator connections for servers that are never going to be used as interactive applications servers. If I’m setting up a new web server or SQL server, there’s no reason I shouldn’t be able to have three or five or 10 administrators logged in at once.
Went to send a fax today on my Lenovo Z61t and the fax service was completely missing, which is strange since I’ve faxed from this machine before. When I tried to reinstall got the 0x4b8 error. The fix was this line:
esentutl /p %windir%\security\database\secedit.sdb
From this forum thread.