I made this suggestion some while back, because SSD's are limited in size [as compared to HDD's] but I got the argument that WB skins become OS specific when installed, and in a dual boot environment [which I had at the time] it would not be ideal... hence the skin files are written to the public documents folder to save confusion.  I still think, though, that we should have the choice to store Stardock skins off-drive in D:, E: or wherever we have the space.

This was another very bad move on Microsoft's part.  I have NO public users on my PC, and thus I have only one user account... MINE.  A public folder is therefore NOT required on MY rig... and it SHOULD NOT be enabled by default that various files are put there WITHOUT my consent.  I mean, who the f**k is Microsoft to tell me where I store certain files on MY computer?  And I wouldn't be the only person who feels this way.

Like the OEM restrictions MS plans to introduce for Win 8, and calling them security measures, this user account thing is just another way MS controls and monitors its users. 

Can't remember exactly where I read this [a Microsoft related forum somewhere] but the reason MS insists that program 'extras' and the like are installed to public folders is so that it can monitor what you have installed [and whether it's legit] via Windows Defender and Security Essentials.  According to the article, if these files were installed to another physical drive, then MS cannot see or monitor them.  Why Microsoft would want to see/monitor my skin files, beats me, but that apparently is the reason we HAVE to have shit installed somewhere other than we'd like it.

For mine, 3rd party developers should go and tell Microsoft to go and get stuffed.

Nothing finer than a great meal out and than coming home to see that I've spent time out of my all too short life (and getting shorter) that I'll never get back.

You don't have one. If you want to modify your system, that's your business, but don't come here, waste everyone's time, than ante up after 2 pages on a thread of your modifications and than have the temerity to call it a WB bug.

I know you'll have trouble comprehending this, but there are actually people here that have problems that are not self-inflicted. So, if only for me, take a number, go to the back of the line and stay there until you hear your number called..........

Starkers....since the OP is 'resolved' ... we can digress....

I hardly think the placement is so that MS can monitor what's installed....that's strictly 'tinfoil hat' territory.

Reality is...standardizing where programs place their component 'crap' actually lessens dramas  PROVIDED some compulsive 'fiddler' doesn't take it upon himself to re-arrange the deck chairs.

Support/Help desks have a hard enough time with NORMAL quirks.  They 'shouldn't' have to check first that every bastardization of an OS possible has not been done before proposing a solution.

The SIMPLEST 'crap' can cause an install to fail.  Example....during the beta of Impulse it totally failed on my system...why? ...because I had [inadvertently] replaced a DEFAULT MS Font with a slightly different one that had no Italic ver.  Something as 'trivial' as that.

So, it's not a Windowblinds 'bug' but actually a demonstration of what can happen when someone 'buggers' a system...;)

It would be good form to edit the post to show it has been solved and was NOT a WindowBlinds issue.

P.S. In the future, please do not break the software on your own. We have updates for that.

Yes, I currently have about 20Gb of data sitting on C:, the last place I want it to be. Cheers Microshaft

Some files you need access to, including my SoaSE mods and maps, are in folders it takes a computer degree to find and access.

I've spent many a happy hour wrestling with file/folder permissions for access to various things I should be able to just click on

How I wish stuff would still work on XP...

Sorry but I disagree, this is a Windowblinds issue. The libraries are a standard feature of Windows 7, why should adding another public library break the software. As I have pointed out, I did not do any crazy customizations to Windows in order to do this, I just added/moved the libraries per the standard Windows 7 mechanism and told Windows to save by default in the other location. This is a STANDARD FEATURE and does NOT "bugger" anything. I DID NOT EVEN REMOVE THE ORIGINAL PUBLIC LIBRARIES FOLDER ON C!

Windowblinds should NOT look in one directory for the skins then need them in another when UAC is run just because I used a standard Windows feature.

Just to add quickly, I checked the environment variable %PUBLIC% and it still points to "C:\Users\Public" on my system, so I've really no logical explanation as to why copying the skins into my D drive public library folder would solve the issue, but it did.

You can if you wish...but you'll be mistaken....;)

Hmm, so if the problem was due to, say, me moving the taskbar to the top of the screen that would not be a Windowblinds bug either? Surely the kinds of people who use Stardock software are the kinds of people who make the most of Windows features like libraries?

Whatever, I'm not turning this into some mud-flinging match. Clearly there's a bug in something for this to have happened. If, as I said, I'd changed things like environment variables or whatever I'd see your point of view, but clearly (either deliberately or inadvertently) I have not.

Cause and effect.

Windowblinds did NOT cause UAC to stop working.  The system's admin took it upon himself to meddle with the default locations of a program's required installation paths....and that caused WB to barf and UAC to go belly-up.

Microsoft doesn't determine such locations on a whim, instead they REQUIRE program coders to use THEIR defined locations for such files, particularly important when shell-related programs [such as OD, WB, etc] 'connect' so closely with the parent OS itself.

Whether or not there may be a 'tweak' that can relocate all your photographs and word documents to some other address is irrelevant as none of those is critical to a system's functioning correctly.

Too many people simply assume that skinning an OS is like plonking a wallpaper on your desktop.   Painless and any twit can do it.  Not so.  Start playing with protected files, folder paths, etc and you strike trouble.  Eventually.

Then move on to shell replacement, commandline modding.....hex editing ....all sorts of fun and you can even break hardware while you're trying...;)

Regardless, I hope what I've discovered here helps someone else and I thank everyone for their suggestions.

[I don't 'skim-read'.... at worst I precis responses]

Perhaps it's HOW you added it...or even WHEN...as in after installing WB but before adding some skins...or vice-versa.

The issue is going to be about UAC 'permissions' associated with whatever new path you created.  Clearly if UAC spat a dummy the permissions were not correct and Windowblinds was the first program to suffer [that you noticed].

There are games....complex games...that can be installed on one machine and simply copy/pasted to an entirely new PC...different OS and all...yet will still function as if directly installed.

But not everything will/can/or is allowed to work that way.

You simply found one of them...;)

I did initially suspect permissions myself but I tested that Administrator had full read/write access to %public%\Documents\Stardock\WindowBlinds by opening an elevated command prompt and then creating a file within that folder.

Perhaps we'll never know, Windows is a complex operating system after all. Frankly though I'm puzzled at peoples opinions that just because I added a new default location for a library (that Windowblinds doesn't use anyway) that I have performed some sort of amazing feat of non-standard Windows hacking that I wasn't telling you all about. To my mind I don't understand at all why that would even affect a program that doesn't use libraries and especially why it would affect it in such a strange way.

The 'new default location' created has clearly affected permissions on the original directory locations to the point that other proggies and functions were upset.

Sometimes 'fiddling' can be like curing the car's oil leak by emptying the sump.  Yes, the leak stops....

...but so does the motor....;)

No, not entirely tin foil hat territory.  I have a rubber suit for those probes foil simply do not prevent.  I wanted to build a lead-lined concrete bunker here for the shit rubber fails to keep out, but council wouldn't approve that due to Health Department restrictions on lead...  apparently something to do with poisoning, 

When they said that, I asked: "Well I suppose asbestos lined is out of the question, then?"

Anyhow, I only repeated what I read... and the writer had a convincing argument to support the theory... ooooh, and how I love a good conspiracy theory, so I'll probably stick with that as it's a whole lot more romantic than your boring old explanation.

I doubt its permissions, possibly there's a NTFS symbolic link or junction that's got screwed up. I'm not 100% on how libraries work at the file system level. Clearly /something/ happened else I would not have had this issue in the first place.

I think for now I'll leave the system as it is, maybe if other faults come to the surface I can narrow down the cause a little more clearly. Are there any other environment variables that Windowblinds uses other than %PUBLIC% that anyone knows of?

Little follow up on this, I actually switched my libraries back to the default, and lo and behold the dreaded UAC not working problem came back again. I was never really satisfied with the resolution to this in the first place, so I set about prodding into the system with Process Monitor etc and sure enough something was still looking on D:, where the old default public library used to be.

Anyway, to cut a long story short, I poked in the registry and found this key:-

HKEY_LOCAL_MACHINE\SOFTWARE\Stardock\WindowBlinds\WB5.ini\Installed

This key was still pointing to D: instead of C: (in spite of doing a complete uninstall/reinstall of WB). Changing this key back to C: cured the problem. Perhaps this is a error in the Windowblinds installer that this key gets created wrong, who knows.

Just thought this would be useful to know if anyone comes up against this problem again.

No...the Windowblinds Installer creates the key correctly...exactly where the installation is SUPPOSED to go to, not where someone else might 'like it to be'.

Millions of people have installed Windowblinds to its correct location without issue.

The fact one individual can 'break' an install does not mean the installer got it wrong - unless by 'installer' you actually mean the person doing the Install....;)

I think this 'support' issue is complete so the thread is closed.