Windows 10: Changes to bcdedit.exe access, or am I having BCD issues?

I'm running Win10 Pro x64 1607. I have a bunch of command scripts that check for elevation with the following line:

Code: for /f "tokens=1,2*" %%a in ('%SystemRoot%\System32\bcdedit.exe') do if (%%a)==(Access) goto :NoAdmin[/quote] Starting about a day ago, all the applicable scripts started going to ":NoAdmin" due to the fact that bcdedit.exe was denying access (and instead issuing an "Access is denied" reply). This happens even if I am using a command window that is elevated:

Code: C:\Temp>%SystemRoot%\System32\bcdedit.exe The boot configuration data store could not be opened.Access is denied.[/quote] Was this due to a recent update? I can't find info on it if it is. I can use another means of detecting elevation, but I want to make sure I'm not just having yet another Win10 issue here.

:)

 

Format doesn't delete broken Windows 10

try to delete the duplicate boot entries in bcd

there are some tools you can use, you can try to use bcdedit.exe to remove the duplicate entry

this still isn't really new to windows 10 so you should be able to search around a bit and use the same procedures for win7/win8 to do this

I don't think reinstalling again will help - you might end up with three installations in the bcd record!

you need to fix the bcd.

if you do bcdedit /enum and you have duplicate entry with exactly the same identifier, you will have to delete it with bcdedit, which should delete BOTH of them, then re-add it with bcdedit which should create only one of them

if they are different then you need to find out which one is the real one and delete the wrong one

I'm not sure how to know for sure which one is the right one - write them both down and try one at a time?

I'm not a bcd expert but pretty sure this is what you need to do

 

Windows 10 installer isn't identifying PAE and the installation won't start

Hello

I have asked help was told to me that it is possible to install systems using a disk image. All I would need was to install Windows 10 in a functional computer to then create a image of the disk and clone it to the notebook's HD.

Then I have installed Windows 10 x86 in my desktop just to create the image. I have reduced the partition to 8,6 GB (the minimum I could) and created a .img file with dd. I have copied the .img file to my external HD and, with the external HD connected to
the notebook, I have cloned the image in the notebook's HD with dd. So it had a Linux partition, then a Logical partition with the cloned Windows 10 x86 and the Linux Swap, and then a NTFS partition with files I need in both Windows and Linux.

However, grub was not finding Windows 10. To make it "find", I have added in the 40_custom file of grub options:

Such way, I can choose Windows 10. However, soon it starts to boot, a crash happens. Here is the screen:
http://i.imgur.com/FFrtKhb.jpg

In the functional Windows 10 of the desktop, I have made a repair pen-drive and a repair CD. Soon the pen-drive repair is loaded, the computer restarts. After some time of the start of the CD, a screen equal this appears:
http://i.imgur.com/SwJvlNa.jpg

The recovery media is asking to use the recovery media. Is there a even more basic recovery tool for Windows 10?

From me search about BCD, I've found there is the bcdedit.exe, which would allow me to add the options proposed by Jessieca.

I suppose I would need to use:

bcdedit.exe /create

bcdedit.exe /set nx AlwaysOff

bcdedit.exe /set pae ForceDisable

However, how the repair CD is not working, I can't use the bcdedit.exe. I tried too to copy bcdedit.exe to a bootable pen-drive with DOS made with a HP utility, and had no success, the bcdedit.exe warned it do not run in DOS mode.

I believe I have to run only that 3 commands and the system will work. How can I run them, knowing not even the repair CD is starting?

 

Sometimes Windows pisses me off so much I just want to use my shotgun on my PC.

Turns out I was having the same issues with DISM, SFC, and probably other native utilities that require elevation. A reboot seems to have "resolved" the issue. (It is not being pedantic to point out that this didn't really "resolve" anything; rather, all it did was work around an issue that obviously still exists.) I guess this is yet another stupid Windows problem.

 

Well if you hadn't logged out after the most recent update (which didn't require a reboot by the way) then your access token may have been out of date for the sessions and administrative access may have been lost. Creating a new one likely "resolved" the issue. I've seen this before.

 

That would make sense (although not being notified of that condition doesn't make sense), but I logged off and back in yesterday. Looks like the last updates were installed on January 24, which was a week ago.