Replies

Here’s the answer. It comes from F. Michael Covington, PhD, the long-serving Windows OS course writer and instructor for Learning Tree International (and with whom I co-taught a Windows 95 course as I was breaking into the ranks at LTree years ago). His latest course is Windows 8/8.1: A Comprehensive Hands-On Introduction. Mike states:

Windows 8.1 has many restrictions placed on the built-in admin account (rid 500). Try creating another account and placing it into the admins group. Then try using the new creds when prompted.

So…. I logged in using my built-in admin account, then created a new user account. CAREFUL! You have to click [Next] on the opening dialog box so as NOT to set up this account using an M$ e-mail login. You can then set it up using Local Account (in M$ parlance). OK, great…. but now what? Now you have to find the new account you just created and edit it to have admin credentials—simple, but easy to miss this all-important step.

You can then log out of your primary admin account, log in with your everyday user account credentials and test things out. I did this be reinstalling a small utility and, when prompted, simply selected the admin account I had just created (it was already selected for me), furnished its password and voila!

Yes, but that is not the point.

With earlier Windows, it was very easy to run whatever while logged on as user, so long as I was able to provide admin credentials. Win 8.1 provides a dialog box to do just that, but then refuses to cooperate when I provide those credentials. Herein is the crux of the matter, and having to repeatedly switch, then log in with my admin account is a nuisance I’m trying to eliminate.

Yes it does, but that’s not the point here and I don’t want this thread hijacked. That said, both REGEDIT and its counterpart are displayed exactly the same, so I’m left wondering if MS retired the former and just copied REGEDIT.EXE to REGEDT32.EXE.

(The EXE is located in the SYSTEM32 subfolder.)

Please reread the original question, as this is a matter of running anything from my user account while (successfully) submitting admin credentials.

Yes. Although instead of a shortcut, I just tried Run As Administrator after right-clicking REGEDT32.EXE.

At first I was unable to even open the resultant CBS.LOG file as admin.

But I tried again several hours later as STD_USER, successfully instructing the OS to allow me to do so using my admin creds. This is a portion of what it reported, pertaining to certain files that sfc /scannow could not repair:

000007fd [SR] Cannot repair member file [l:36{18}]”Amd64CNBJ2530.DPB” of prncacla.inf, Version = 6.3.9600.16384, pA = PROCESSOR_ARCHITECTURE_AMD64 (9), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type = [l:24{12}]”driverUpdate”, TypeName neutral, PublicKey neutral in the store, hash mismatch
000007ff [SR] Cannot repair member file [l:36{18}]”Amd64CNBJ2530.DPB” of prncacla.inf, Version = 6.3.9600.16384, pA = PROCESSOR_ARCHITECTURE_AMD64 (9), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type = [l:24{12}]”driverUpdate”, TypeName neutral, PublicKey neutral in the store, hash mismatch

Now I’m not sure why Win 8.1 was trying to repair a file(s) pertaining to an AMD processor when, if the routine bothered to first poll the registry, it would quickly discover that I was running it on an Intel-powered box. Anyway, the fact that I could finally do something at the STD_USER level using admin creds. gives me hope that the scan procedure did, in fact, repair something that was preventing the use of these higher-level creds. while logged as STD_USER.

Incidentally, when I used the approved M$ procedure to upgrade from 8.0 to 8.1, I was dismayed to learn that the upgrade messed with many personal settings, including some for apps where the upgrade had no business. For example, I run J River Media Center and the upgrade blew out all of my app-centric playlists. I have never seen such errant behavior for a simple upgrade, and I’ve been using Windows since version 1.0 (a runtime version that shipped with the first Aldus PageMaker back in ’86). I’ve also participated in many Windows beta programs over the years, so this upgrade was a bit bizarre in its overall performance.

“I do this and then NOTHING happens.”

What part of this is confusing? Sorry, but your assessment is correct… the app does not run. When I wrote that “NOTHING happens,” that’s what that means. The app does not run with my admin credentials. Only when I physically switch users to my admin account am I able to proceed with the app upgrade/installation, or whatever it is that requires admin credentials before it will proceed. This is NOT how prior versions of Windows behaved (and isn’t the only bizarre behavior I’ve encountered when I upgraded to 8.1 from 8.0).

Maybe ask Fred or Woody if they’ve run into this?

No, it’s already entered.

If only it were so easy. (This is not the solution I’m seeking.)

When I’m logged on using my standard user account and an app requires admin rights, it lets me pop up a box that is divided horizontally. One option is to use a smartcard; the other is to run as my admin acct. I choose to run as my admin acct, which then produces a field in which I am to enter my admin password. I do this and then NOTHING happens.

This is the problem; Win 8.1 won’t let me run anything requiring admin rights when I’m logged on using my standard user account.

I couldn’t agree more. Twenty years ago I was a Zen master of batch file programming (and was even an uncredited technical editor of the MS-DOS 6.2 User Guide). I’ve never seen anything like it, either. It makes no logical sense and my testing revealed it had nothing to do with using Notepad as the editor, nor corrupt sysvars (as witnessed by the change in coding approach—written in Notepad again—working as expected).

Problem solved. This works (Win XP):

set “path1=C:Documents and Settings”
set path2=%username%
set “path3=My DocumentsDownloads”
set path4=%path1%%path2%%path3%
echo %path4%
pause

I wish it were that simple.

Paul, Notepad did not add any characters. I’ve viewed my test file in Notepad++ and engaged Show All Chars, but there is no spurious character added by Notepad.

And BATcher, this three-line batch file, when engaged from a prompt, yields the same previous result. (Adding quotes on either side of the sysvar matters not.)

echo %username%
pause
exit

~~~~~~~~~~~

C:Documents and SettingsMy DocumentsDownloads>■e
‘■e’ is not recognized as an internal or external command,
operable program or batch file.

Again, I’ve been testing this on three machines, created the CMD from scratch each time and also testing many versions in an attempt to find something that works. In answer to your question, then, all of the sysvars are kosher; there are no spurious characters introduced, especially in relation to %userprofile%.

Please note that I’m writing this for another, non-techie user located in another state. I have no idea what they’ve chosen as their username, hence your “if /i” test doesn’t help me at all (I do not know the right side of the string comparison).

When I echo %userprofile& from a CMD prompt I, too, get the expected result. This also confirms that there is nothing amiss with this sysvar.

I’ve tried using many different things on the first line of the batch file, including a basic @echo off. It seems that so long as there is a referenced %userprofile% somewhere in the file, it returns the same error, substituting the first character for @ shown below:

prompt>■@[/FONT]
‘■@’ is not recognized as an internal or external command,[/FONT]
operable program or batch file.[/FONT]

My real question is how do I test for the %userprofile% and then be able to CD to that test result?

This isn’t really the answer to my problem. Consider a one-line CMD batch file:

echo %userprofile% [I]or any other sysvar[/I]

This returns:

C:UsersMeDesktop>■e[/FONT]
‘■e’ is not recognized as an internal or external command,[/FONT]
operable program or batch file.

[/FONT]

Now today I’m on yet a third machine and have again created this file from scratch. I’m not copying and pasting. There is no spurious character prefacing the ‘e’ in echo.[/FONT][/FONT]

Nope. I’ve created the file from scratch in Notepad several times on both machines. The spurious character is only introduced as the command interpreter attempts to run the file.

The crazy thing is that this DOES work:

@echo off
c:
cd %programfiles%Classic Shell
if not exist ClassicShell.chm echo It doesn’t exist.