Error While Powering on VMware Player on Windows 10

As I went through one of the many Windows 10 beta updates, my VMware Player started throwing “Error while powering on: Internal error.” After reboot everything started working again so I just assumed it was simply some fluke in the upgrade process. And then it happened again a bit later. This time a single restart didn’t help but it did start working after a few of them. Every restart was like a coin toss. It smelled like a race condition.

One of things I checked was status of VMware’s services. There I noticed that, although startup type was set to Automatic, VMware Authorization Service was not running at times. And I could match the times when it was not running with the error. Even better, error would disappear as soon as I would manually start that service. My best guess, based on observed behavior, was that VMware Authorization Service needed some other service to start beforehand. However, dependencies for that service were missing. All VMware’s service needed was a bit more time.

Fortunately, Windows has one great feature enabling just that ever since Windows Vista. All needed is to change startup type to Automatic (Delayed Start) and your service will wait a bit extra time before starting. Original idea of this feature was to alleviate system load at startup by postponing some tasks for just a bit later when CPU had a chance to breathe. But, as a side effect, we can be sure that pretty much all important system services are already up by the time delayed start kicks in.

Might not be an ideal solution but I had no issues with it.

PS: Proper solution would be to find the missing dependency and add it to service. But setting up dependencies is not an easy task and pretty much becomes just trial-and-error adventure unless you know the product on the source code level. Not worth it.

MagiWOL 3.41

It was a long overdue task to release new MagiWOL. Changes have been small but noticeable.

Finally there is a high-DPI support with multiple icon sizes to make application presentable on all these new displays out there. If you use classic display only difference will be in what icons you see. But if you are using anything that makes Windows want to scale icons, you should be able to enjoy extra crispy icons.

Those using import functionality will be happy that, beside ranges, now you can defined network subnet size. Not a big change but it will make life easier for some.

Other changes are pretty much just bug-fixes and cleanup of my development environment.

As always, download is available on these pages or from within application.

Unsung Hero

I often write and speak about gadgets I get for myself and how I use them. However, there is one gadget I never wrote about and I use it pretty much every day ever since I got my first one in the late 1997. Those knowing me personally are aware how rare I remember year when something happened so this is something special to me. It is my pen.

There are many like it, but this one is mine. :)

As with many drugs, the first one I received as a gift. It was an Uni-ball Signo DX with a 0.38 tip. Compared to roller pens I used before this one was just sliding without any conscious effort and lines were as thin as a spider web. I watched with dread ink level getting lower and lower. Fortunately I was able to secure the new source before it came to worst. And, in times before Internet, this was a feat.

Then miracle happened and store in my town got quite respectable assortment of Mitsubishi pens. Over the years I tried many of them finally settling on Signo 207 RT (0.5 mm tip) a few years ago. It is quite a similar pen to DX with an advantage of being retractable so I couldn’t lose cap anymore. And switch to a slightly larger tip brought another level of sliding bliss.

I am sure there are pens other find better and have I tried many of them. However, this one works for me and that is all that matters.

Maybe I am an old-fashioned guy but writing and sketching really helps me to think and solve problems. Having a comfortable pen in hand makes a ton of difference.

PS: Those interested in Uni-ball pens can check their godawful web pages. I only wish their pages would be as good as their pens.

Git and Windows Cannot Access the Specified Device

I am not really sure what happened (although I am willing to place some blame on Git file attribute handling) but suddenly some of my batch files started reporting “Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item.” when I try to start them from Windows Explorer. Annoyingly I could still start that same batch from Windows command line. Only double-click wouldn’t work.

After short investigation culprit was found in the permissions. Some application (Git) changed permissions for the file to include only read permissions. As soon as I changed permissions to include executable, I could start script again. Heck there is even a way to get executable attribute into Git repository so this can be avoided in the future. However, I took this as an opportunity to update permissions for my drive.

Drive in question is NTFS but not because I need any permission handling capabilities. Mostly it is because way NTFS handles small files is superior to any other Windows-supported file system. So my permissions on given drive are literally just allowing all users access. With time and different computers this changed a bit so reset was in order. I wanted to allow all users full drive access.

After starting Command Prompt as an administrator first mandatory task was to switch to that drive. Not only that this allows me to use relative paths further down the road but it also makes it less likely that any errors (e.g. due to accidentally forgotten parameter) would impact my system drive.

A:

Next step was to take ownership of my whole drive, forcing change when necessary:

TAKEOWN /F * /R /D Y
 SUCCESS: The file (or folder): "A:\Test\Test1.txt" now owned by user "TEST\Josip".
 SUCCESS: The file (or folder): "A:\Test\Test2.txt" now owned by user "TEST\Josip".
 SUCCESS: The file (or folder): "A:\Test\Test3.txt" now owned by user "TEST\Josip".
...

Since previous command left a lot of output, I also used /setowner option of ICACLS. There is no benefit to this one other than showing me stats and ensuring a file hasn’t been missed. Yes, you can even use this command instead of TAKEOWN but it has no option of forcing ownership change so you might need TAKEOWN regardless.

ICACLS .\ /setowner Josip /T /C /Q
Successfully processed 119121 files; Failed processing 0 files

Next I set my root directory to allow all Users, Administrators, and SYSTEM groups in. From previous run I had Everyone and BUILTIN set so I decided to remove them while I am at it.

ICACLS .\ /grant:r Users:F Administrators:F SYSTEM:F /inheritance:e /remove Everyone /remove BUILTIN
 processed file: .\
 Successfully processed 1 files; Failed processing 0 files

And last step was what I really wanted. Just reset all permissions.

ICACLS * /reset /T /C /Q
 Successfully processed 119120 files; Failed processing 0 files

And now I have my drive just as I wanted it.

PS: If you just wanna sort out Git, you can also update executable bit and avoid whole issue.

Embedding Resources Without Pesky Resources Folder

Adding image resources to your C# application is close to trivial. One method is to open your Resources.resx file and simply add bitmaps you wish to use. However, this leaves your with all images in Resources folder. Some people like it that way but I prefer to avoid it - I prefer the old-style system of keeping it all in your resource file.

To have all images included in resource instead being in a separate folder, just select offending resources and press F4 to bring Properties window. Under Persistence simply select Embedded in .resx and your resources are magically (no real magic involved) embedded into resx file as Base-64 encoded string. Only thing remaining is to delete leftover folder.

You use resources from application same as you normally would.