I'm on Windows 8.1 trying to disable my clickpad programatically. I've installed the correct x64 bit version of devcon as noted here. I can find the correct device but devcon disable with the same parameters fails.
PS C:\...\7600.16385.win7_wdk.100208-1538\tools\devcon\amd64> .\devcon.exe disable 'ACPI\SYN1ECA*'
ACPI\SYN1ECA\4&22077A96&0 : Disable failed
No matching devices found.
Which is rather confusing. It obviously finds the right device, but then reports "No matching devices found". What the heck?
Please note that I am aware of this similar question but, in addition to not having an accepted answer, that question has a different error and is likely using the wrong version of devcon.
No Matching Devices is the way that windows tells you that it cannot find or access the devices you are looking for. There can be a couple of causes for this:
Incorrect Permissions caused by not running the command prompt/BAT as an administrator. Simply right-click the relevant access method and select 'Run as administrator"
Incorrect Access caused by running the wrong version of devcon.exe. As a remnant of the shift to 64 bit computer there are two version of devcon located in the 'Tools' folder, one for x86 and one for x64, ensure that you are running the correct version for your computer and you should be able to perform your tasks without issue.
You are using the wrong "spelling" in your command.
This should work:
devcon.exe disable "ACPI\SYN1ECA*"
If you already found the exact device you want to disable you can do it like this:
devcon.exe disable "#<instace ID>"
In your case:
devcon.exe disable "#ACPI\SYN1ECA\4&22077A96&0"
If this also doesn't work you should use the remove command. remove works almost always, but the device will be back after you restart the system.
devcon.exe remove "#<instance ID>"
No matching devices found. is a confusing way for devcon to tell that you are running the command without elevation. This is without elevation:
devcon restart "PCI\VEN_10EC&DEV_8168&SUBSYS_85051043&REV_09"
PCI\VEN_10EC&DEV_8168&SUBSYS_85051043&REV_09\4&21A1C3AE&0&00E5: Restart failed
No matching devices found.
This is with elevation:
devcon restart "PCI\VEN_10EC&DEV_8168&SUBSYS_85051043&REV_09"
PCI\VEN_10EC&DEV_8168&SUBSYS_85051043&REV_09\4&21A1C3AE&0&00E5: Restarted
1 device(s) restarted.
To elevate right click on command prompt and select "run as administrator".
Look at superuser question
Resume:
To download correct version devcon x86/x64. Run the devcon commands in cmd.exe with administrative privileges
To block/unblock:
USB\VID_1C4F&PID_0002&MI_01\6&1578F7C2&0&0001 : USB storage device
%windir%\system32\devcon.exe disable *VID_1C4F*
and
%windir%\system32\devcon.exe enable *VID_1C4F*
Sometimes devcon does not disable:
USB\VID_1C4F&PID_0002&MI_01\6&1578F7C2&0&0001 : Disabled
HID\VID_1C4F&PID_0002&MI_00\7&2B89365C&0&0000 : Disable failed
In this case, the only solution is replace the command: "disable" by "remove":
%windir%\system32\devcon.exe remove *VID_1C4F*
HID\VID_1C4F&PID_0002&MI_00\7&2B89365C&0&0000 : Removed
1 device(s) were removed.
But devcon is not a permanent solution for locking and unlocking devices.
The test is that you can lock a usb device and then run bash script renewusb_2k.bat, and you will see that the script reinstall the usb drivers again and the locked usb device becomes accessible again.
Programmatic approach in Python. What ended up working for me as well was of course Running as Administrator my app and the remove device(s) / rescan trick:
DevConFX3Regex = re.compile(r'(?P<device_id>USB[^\s]*)\s+ : FX3')
DevConCOMRegex = re.compile(r'(?P<device_id>[^\s]*)\s+ : .*\(COM[0-9]{1,3}\).*')
def auto_repair_usb_com_ports(self):
os.system('devcon findall * > DevCon.txt')
with open('DevCon.txt', 'r') as devcon_text:
devcon_text = devcon_text.read()
for match in self.DevConFX3Regex.finditer(devcon_text):
device_id = match.group("device_id")
print(device_id)
device_id = f'"#{device_id}"'
os.system(f'devcon remove {device_id}')
for match in self.DevConCOMRegex.finditer(devcon_text):
device_id = match.group('device_id')
device_id = f'"#{device_id}"'
os.system(f'devcon remove {device_id}')
os.system('devcon rescan')
Related
On another computer running win7 Pro i had no issue and i was using my.bat file with success. Now on my new win10 Home computer i get this error:
C:\Users\User>schtasks /change /tn "AlarmClockEarly" /ENABLE
ERROR: Access is denied.
But if i run the actual state of the task (for example if it is already disabled) i get this:
INFO: Scheduled task "AlarmClockEarly" has already been disabled.
SUCCESS: The parameters of scheduled task "AlarmClockEarly" have been changed.
The task as you can see is a custom made and i don't try to mess with Windows like disabling Updates or something plus i already checked the run with highest priviledges
I run cmd as an Administrator
I am already the Admin account in this PC
I also tried running the command and the .bat itself from the place it is stored C:\Users\User\Scripts>
Can't remember how many things i tried while searching for a solution. So you are my best hope and thank you in advance.
Well i found the solution and for anyone searching the same you ll have to go to C:\windows\system32 then find cmd and go to Properties -> Security. While SYSTEM is highlighted press Advanced at the bottom right and change the Owner from whatever to your account.
I've a Xerox DocuColor 250, and windows 10. I'm trying to fix a problem that will crash any program when I go to printer preferences.
The strange thing is that: if I open the control panel, printer preferences works good whitout any problem. But if I open printer preferences from for example Word the program will crash and close. On the event viewer I see:
The module that generated the error: harmony10.dll, version: 2.6.102.0.
The path: ": C:\Windows\system32\spool\DRIVERS\x64\3\harmony10.dll"
The error offset "0x00000000000f5dc0"
How is possible that the same thing on the control panel won't crash but with a program it crash with this error?
If the problem won't solved with some windows-tricks, how can I track and debug a program and check what thing don't work and trying to "hack" the dll to bypass the error?
Delete all software associated with the printer, open the command line
and execute the printui /s command.
Next, look for your printer and remove the driver completely.
then install driver into printer disk or download here http://www.support.xerox.com/support/docucolor-240-250/downloads/enus.html?operatingSystem=win10
Also, try to open a command prompt on behalf of the administrator and enter:
net stop spooler
del %systemroot%\system32\spool\printers\*.*
net start spooler
exit
I have been running VMware for the last year no problems, today I opened it up to start one of my VM and get an error message, see screen shot.
I did follow the link and went through the steps, on step 4 I need to mount a volume using "mountvol".
when I try to mount a volume using mountvol X: \\?\Volume{5593b5bd-0000-0000-0000-c0f373000000}\ it keeps saying The directory is not empty. I even created a partition with 2GB and still the same message.
My Questions:
How can I mount the volume that is not empty even though it is?
Why did this Device/Credential Guard auto enable itself and how can I get rid of it or disable it.
CMD:
There is a much better way to handle this issue. Rather than removing Hyper-V altogether, you just make alternate boot to temporarily disable it when you need to use VMWare. As shown here...
http://www.hanselman.com/blog/SwitchEasilyBetweenVirtualBoxAndHyperVWithABCDEditBootEntryInWindows81.aspx
C:\>bcdedit /copy {current} /d "No Hyper-V"
The entry was successfully copied to {ff-23-113-824e-5c5144ea}.
C:\>bcdedit /set {ff-23-113-824e-5c5144ea} hypervisorlaunchtype off
The operation completed successfully.
note: The ID generated from the first command is what you use in the second one. Don't just run it verbatim.
When you restart, you'll then just see a menu with two options...
Windows 10
No Hyper-V
So using VMWare is then just a matter of rebooting and choosing the No Hyper-V option.
If you want to remove a boot entry again. You can use the /delete option for bcdedit.
First, get a list of the current boot entries...
C:\>bcdedit /v
This lists all of the entries with their ID's. Copy the relevant ID, and then remove it like so...
C:\>bcdedit /delete {ff-23-113-824e-5c5144ea}
As mentioned in the comments, you need to do this from an elevated command prompt, not powershell. In powershell the command will error.
update:
It is possible to run these commands in powershell, if the curly braces are escaped with backtick (`). Like so...
C:\WINDOWS\system32> bcdedit /copy `{current`} /d "No Hyper-V"
Device/Credential Guard is a Hyper-V based Virtual Machine/Virtual Secure Mode that hosts a secure kernel to make Windows 10 much more secure.
...the VSM instance is segregated from the normal operating
system functions and is protected by attempts to read information in
that mode. The protections are hardware assisted, since the hypervisor
is requesting the hardware treat those memory pages differently. This
is the same way to two virtual machines on the same host cannot
interact with each other; their memory is independent and hardware
regulated to ensure each VM can only access it’s own data.
From here, we now have a protected mode where we can run security
sensitive operations. At the time of writing, we support three
capabilities that can reside here: the Local Security Authority (LSA),
and Code Integrity control functions in the form of Kernel Mode Code
Integrity (KMCI) and the hypervisor code integrity control itself,
which is called Hypervisor Code Integrity (HVCI).
When these capabilities are handled by Trustlets in VSM, the Host OS
simply communicates with them through standard channels and
capabilities inside of the OS. While this Trustlet-specific
communication is allowed, having malicious code or users in the Host
OS attempt to read or manipulate the data in VSM will be significantly
harder than on a system without this configured, providing the
security benefit.
Running LSA in VSM, causes the LSA process itself (LSASS) to remain in
the Host OS, and a special, additional instance of LSA (called LSAIso
– which stands for LSA Isolated) is created. This is to allow all of
the standard calls to LSA to still succeed, offering excellent legacy
and backwards compatibility, even for services or capabilities that
require direct communication with LSA. In this respect, you can think
of the remaining LSA instance in the Host OS as a ‘proxy’ or ‘stub’
instance that simply communicates with the isolated version in
prescribed ways.
And Hyper-V and VMware didn't work the same time until 2020, when VMware used Hyper-V Platform to co-exist with Hyper-V starting with Version 15.5.5.
How does VMware Workstation work before version 15.5.5?
VMware Workstation traditionally has used a Virtual Machine Monitor
(VMM) which operates in privileged mode requiring direct access to the
CPU as well as access to the CPU’s built in virtualization support
(Intel’s VT-x and AMD’s AMD-V). When a Windows host enables
Virtualization Based Security (“VBS“) features, Windows adds a
hypervisor layer based on Hyper-V between the hardware and Windows.
Any attempt to run VMware’s traditional VMM fails because being inside
Hyper-V the VMM no longer has access to the hardware’s virtualization
support.
Introducing User Level Monitor
To fix this Hyper-V/Host VBS compatibility issue, VMware’s platform
team re-architected VMware’s Hypervisor to use Microsoft’s WHP APIs.
This means changing our VMM to run at user level instead of in
privileged mode, as well modifying it to use the WHP APIs to manage
the execution of a guest instead of using the underlying hardware
directly.
What does this mean to you?
VMware Workstation/Player can now run when Hyper-V is enabled. You no
longer have to choose between running VMware Workstation and Windows
features like WSL, Device Guard and Credential Guard. When Hyper-V is
enabled, ULM mode will automatically be used so you can run VMware
Workstation normally. If you don’t use Hyper-V at all, VMware
Workstation is smart enough to detect this and the VMM will be used.
System Requirements
To run Workstation/Player using the Windows Hypervisor APIs, the
minimum required Windows 10 version is Windows 10 20H1 build
19041.264. VMware Workstation/Player minimum version is 15.5.5.
To avoid the error, update your Windows 10 to Version 2004/Build 19041 (Mai 2020 Update) and use at least VMware 15.5.5.
I'm still not convinced that Hyper-V is The Thing for me, even with last year's Docker trials and tribulations and I guess you won't want to switch very frequently, so rather than creating a new boot and confirming the boot default or waiting out the timeout with every boot I switch on demand in the console in admin mode by
bcdedit /set hypervisorlaunchtype off
Another reason for this post -- to save you some headache: You thought you switch Hyper-V on with the "on" argument again? Nope. Too simple for MiRKoS..t. It's auto!
Have fun!
G.
To make it super easy:
Just download this script directly from Microsoft.
Run your Powershell as an admin and then execute following commands:
To Verify if DG/CG is enabled DG_Readiness.ps1 -Ready
To Disable DG/CG. DG_Readiness.ps1 -Disable
For those who might be encountering this issue with recent changes to your computer involving Hyper-V, you'll need to disable it while using VMWare or VirtualBox. They don't work together. Windows Sandbox and WSL 2 need the Hyper-V Hypervisor on, which currently breaks VMWare. Basically, you'll need to run the following commands to enable/disable Hyper-V services on next reboot.
To disable Hyper-V and get VMWare working, in PowerShell as Admin:
bcdedit /set hypervisorlaunchtype off
To re-enable Hyper-V and break VMWare for now, in PowerShell as Admin:
bcdedit /set hypervisorlaunchtype auto
You'll need to reboot after that. I've written a PowerShell script that will toggle this for you and confirm it with dialog boxes. It even self-elevates to Administrator using this technique so that you can just right click and run the script to quickly change your Hyper-V mode. It could easily be modified to reboot for you as well, but I personally didn't want that to happen. Save this as hypervisor.ps1 and make sure you've run Set-ExecutionPolicy RemoteSigned so that you can run PowerShell scripts.
# Get the ID and security principal of the current user account
$myWindowsID = [System.Security.Principal.WindowsIdentity]::GetCurrent();
$myWindowsPrincipal = New-Object System.Security.Principal.WindowsPrincipal($myWindowsID);
# Get the security principal for the administrator role
$adminRole = [System.Security.Principal.WindowsBuiltInRole]::Administrator;
# Check to see if we are currently running as an administrator
if ($myWindowsPrincipal.IsInRole($adminRole))
{
# We are running as an administrator, so change the title and background colour to indicate this
$Host.UI.RawUI.WindowTitle = $myInvocation.MyCommand.Definition + "(Elevated)";
$Host.UI.RawUI.BackgroundColor = "DarkBlue";
Clear-Host;
}
else {
# We are not running as an administrator, so relaunch as administrator
# Create a new process object that starts PowerShell
$newProcess = New-Object System.Diagnostics.ProcessStartInfo "PowerShell";
# Specify the current script path and name as a parameter with added scope and support for scripts with spaces in it's path
$newProcess.Arguments = "-windowstyle hidden & '" + $script:MyInvocation.MyCommand.Path + "'"
# Indicate that the process should be elevated
$newProcess.Verb = "runas";
# Start the new process
[System.Diagnostics.Process]::Start($newProcess);
# Exit from the current, unelevated, process
Exit;
}
Add-Type -AssemblyName System.Windows.Forms
$state = bcdedit /enum | Select-String -Pattern 'hypervisorlaunchtype\s*(\w+)\s*'
if ($state.matches.groups[1].ToString() -eq "Off"){
$UserResponse= [System.Windows.Forms.MessageBox]::Show("Enable Hyper-V?" , "Hypervisor" , 4)
if ($UserResponse -eq "YES" )
{
bcdedit /set hypervisorlaunchtype auto
[System.Windows.Forms.MessageBox]::Show("Enabled Hyper-V. Reboot to apply." , "Hypervisor")
}
else
{
[System.Windows.Forms.MessageBox]::Show("No change was made." , "Hypervisor")
exit
}
} else {
$UserResponse= [System.Windows.Forms.MessageBox]::Show("Disable Hyper-V?" , "Hypervisor" , 4)
if ($UserResponse -eq "YES" )
{
bcdedit /set hypervisorlaunchtype off
[System.Windows.Forms.MessageBox]::Show("Disabled Hyper-V. Reboot to apply." , "Hypervisor")
}
else
{
[System.Windows.Forms.MessageBox]::Show("No change was made." , "Hypervisor")
exit
}
}
the simplest solution for this issue is to download the "Device Guard and Credential Guard hardware readiness tool" to correct the incompatibility :
https://www.microsoft.com/en-us/download/details.aspx?id=53337
Decompress the zip
you will find :
execute the "DG_Readiness_Tool_v3.6.ps1" with PowerShell
Now you should be able to power on your virtual machine normally .
I don't know why but version 3.6 of DG_Readiness_Tool didn't work for me.
After I restarted my laptop problem still persisted.
I was looking for solution and finally I came across version 3.7 of the
tool and this time problem went away.
Here you can find latest powershell script:
DG_Readiness_Tool_v3.7
I also struggled a lot with this issue. The answers in this thread were helpful but were not enough to resolve my error. You will need to disable Hyper-V and Device guard like the other answers have suggested. More info on that can be found in here.
I am including the changes needed to be done in addition to the answers provided above. The link that finally helped me was this.
My answer is going to summarize only the difference between the rest of the answers (i.e. Disabling Hyper-V and Device guard) and the following steps :
If you used Group Policy, disable the Group Policy setting that you
used to enable Windows Defender Credential Guard (Computer
Configuration -> Administrative Templates -> System -> Device Guard
-> Turn on Virtualization Based Security).
Delete the following registry settings:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\LsaCfgFlags
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\DeviceGuard\EnableVirtualizationBasedSecurity
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\DeviceGuard\RequirePlatformSecurityFeatures
Important :
If you manually remove these registry settings, make sure to delete
them all. If you don't remove them all, the device might go into
BitLocker recovery.
Delete the Windows Defender Credential Guard EFI variables by using
bcdedit. From an elevated command prompt(start in admin mode), type
the following commands:
mountvol X: /s
copy %WINDIR%\System32\SecConfig.efi X:\EFI\Microsoft\Boot\SecConfig.efi /Y
bcdedit /create {0cb3b571-2f2e-4343-a879-d86a476d7215} /d "DebugTool" /application osloader
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} path "\EFI\Microsoft\Boot\SecConfig.efi"
bcdedit /set {bootmgr} bootsequence {0cb3b571-2f2e-4343-a879-d86a476d7215}
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} device partition=X:
mountvol X: /d
Restart the PC.
Accept the prompt to disable Windows Defender Credential Guard.
Alternatively, you can disable the virtualization-based security
features to turn off Windows Defender Credential Guard.
install the latest vmware workstation > 15.5.5 version
which has support of Hyper-V Host
With the release of VMware Workstation/Player 15.5. 5 or >, we are
very excited and proud to announce support for Windows hosts with
Hyper-V mode enabled! As you may know, this is a joint project from
both Microsoft and VMware
https://blogs.vmware.com/workstation/2020/05/vmware-workstation-now-supports-hyper-v-mode.html
i installed the VMware.Workstation.Pro.16.1.0
and now it fixed my issue now i am using docker & vmware same time even my window Hyper-V mode is enabled
Windows 1909 (18363.1377)
In my case I was using windows 1909, Device Guard was disabled and so was the Hyper V. While trying docker I installed and enabled wsl2. After uninstalling wsl from control panel and disabling it from powershell my vmware started working again.
Following is the command to disable wsl
Run in powershell as admin
dism.exe /online /disable-feature /featurename:Microsoft-Windows-Subsystem-Linux
Uninstall WSL shown in the screenshot
Reboot your system
If you are someone who maintains an open customized "Run as administrator" command prompt or powershell command line window at all the times you can optionally setup the following aliases / macros to simplify executing the commands mentioned by #gue22 for simply disabling hyper-v hypervisor when needing to use vmware player or workstation and then enabling it again when done.
doskey hpvEnb = choice /c:yn /cs /d n /t 30 /m "Are you running from elevated command prompt" ^& if not errorlevel 2 ( bcdedit /set hypervisorlaunchtype auto ^& echo.^&echo now reboot to enable hyper-v hypervisor )
doskey hpvDis = choice /c:yn /cs /d n /t 30 /m "Are you running from elevated command prompt" ^& if not errorlevel 2 ( bcdedit /set hypervisorlaunchtype off ^& echo.^&echo now reboot to disable hyper-v hypervisor )
doskey bcdL = bcdedit /enum ^& echo.^&echo now see boot configuration data store {current} boot loader settings
With the above in place you just type "hpvenb" [ hypervisor enabled at boot ], "hpvdis" [ hypervisor disabled at boot ] and "bcdl" [ boot configuration devices list ] commands to execute the on, off, list commands.
Well Boys and Girls after reading through the release notes for build 17093 in the wee small hours of the night, I have found the change point that affects my VMware Workstation VM's causing them not to work, it is the Core Isolation settings under Device Security under windows security (new name for windows defender page) in settings.
By default it is turned on, however when I turned it off and restarted my pc all my VMware VM's resumed working correctly. Perhaps a by device option could be incorporated in the next build to allow us to test individual devices / Apps responses to allow the core isolation to be on or off per device or App as required .
Here are proper instructions so that everyone can follow.
First download Device Guard and Credential Guard hardware readiness tool from this link: https://www.microsoft.com/en-us/download/details.aspx?id=53337
extract the zip folder content to some location like: C:\guard_tool
you will have files like this copy file name of ps1 extension file in my case its v3.6 so it will be : DG_Readiness_Tool_v3.6.ps1
Next click on start menu and search for powershell and then right click on it and run as Administrator.
After that you will see blue color terminal enter command cd C:\guard_tool , replace the path after cd with your extracted location of the tool
Now enter command: .\DG_Readiness_Tool_v3.6.ps1 -Disable
After that reboot system
When your system is restarting it boot time system will show notification with black background to verify that you want to disable these features so press F3 to confirm.
do +1 if it helped :)
QUICK SOLUTION EVERY STEP:
Fixed error in VMware Workstation on Windows 10 host
Transport (VMDB) error -14: Pipe connection has been broken.
Today we will be fixing VMWare error on a windows 10 computer.
In RUN box type "gpedit" then Goto [ERROR SEE POINT 3]
1- Computer Configuration
2- Administrative Templates
3- System - Device Guard : IF NO DEVICE GUARD : (DOWNLOAD https://www.microsoft.com/en-us/download/100591 install this "c:\Program Files (x86)\Microsoft Group Policy\Windows 10 November 2019 Update (1909)\PolicyDefinitions" COPY to c:\windows\PolicyDefinitions )
4- Turn on Virtualization Based Security.
Now Double click that and "Disable"
Open Command Prompt as Administrator and type the following
gpupdate /force [DONT DO IF YOU DONT HAVE DEVICE GUARD ELSE IT WILL GO AGAIN]
Open Registry Editor, now Go to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceGuard. Add a new DWORD value named EnableVirtualizationBasedSecurity and set it to 0 to disable it.
Next Go to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA. Add a new DWORD value named LsaCfgFlags and set it to 0 to disable it.
In RUN box, type Turn Windows features on or off, now uncheck Hyper-V and restart system.
Open command prompt as a administrator and type the following commands
bcdedit /create {0cb3b571-2f2e-4343-a879-d86a476d7215} /d "DebugTool" /application osloader
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} path "\EFI\Microsoft\Boot\SecConfig.efi"
bcdedit /set {bootmgr} bootsequence {0cb3b571-2f2e-4343-a879-d86a476d7215}
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO,DISABLE-VBS
bcdedit /set hypervisorlaunchtype off
Now, Restart your system
I had the same problem. I had VMware Workstation 15.5.4 and Windows 10 version 1909 and installed Docker Desktop.
Here how I solved it:
Install new VMware Workstation 16.1.0
Update my Windows 10 from 1909 to 20H2
As VMware Guide said in this link
If your Host has Windows 10 20H1 build 19041.264 or newer,
upgrade/update to Workstation 15.5.6 or above.
If your Host has Windows 10 1909 or earlier, disable Hyper-V on the host to resolve this issue.
Now VMware and Hyper-V can be at the same time and have both Docker and VMware at my Windows.
I have a module in vfp9 running under windows 7 32bits, this module prints in a local printer using the command COPY FILE file.txt TO \\server\printer, locally works fine, but in other pc of the network doesn't work, the error cannot create file \\server\printer shows.
In windows xp, this works fine, but in windows 7 not, I guess is a permission, wich one? where I can find information about this? I disabed the option "disable sharing with password protection" in advanced config of network and I can see all the shared resources, disks and printers.
I appreciate any help
That's a very 'legacy' way of printing and I wouldn't rely on it. If you have to do it this way, try redirecting an LPT port and then copying to the LPT port. At a CMD prompt:
net use lpt3 \\server\printer /yes
Then in your application
copy file file.txt to lpt3
I am attempting to install PostgreSQL 9 (postgresql-9.0.3-1-windows.exe) on my WinXP machine and get the following error at the start:
Some googling around yielded some advice that suggested Windows Scripting Host might be disabled. I've checked and WSH is definitely enabled, so it must be something else. Question is, what?
I can see a file called prerun_checks.vbs is created in %TEMP% and when I try to run this manually, I get the following:
Which looks like a permissions error. However, I am an Admin, and I've given myself full control of the temp folder and it's still not working.
Any help appreciated.
In my case the solution was related to NotePad++ being the default application for opening .vbs files. If you have the same situation, here's an elaborate solution:
http://igordcard.blogspot.co.il/2012/03/unable-to-write-inside-temp-environment.html
In a nutshell, in the registry, you need to go to HKEY_CLASSES_ROOT\.vbs, and set the (Default) entry back to the string VBSFile.
This is a an old thread, but I just had the same problem on windows 10:
Unable to write inside TEMP environment path
Solve by the following steps
Check that the problem is related to Windows Script Host.
From cmd run wscript.exe
If you get an error Windows Script Host is not enabled then you can solved it by running the following from cmd
Fix for Current User
REG DELETE "HKCU\SOFTWARE\Microsoft\Windows Script Host\Settings" /v Enabled /f
Fix for Local Machine
REG DELETE "HKLM\SOFTWARE\Microsoft\Windows Script Host\Settings" /v Enabled /f
Now you can install psql
As I was finishing off my question above, our IT chap turned up and knew what the problem was immediately: it's McAfee. It prevents anything from running in a TEMP folder, including Windows Scripting Host scripts. Disabling McAfee for the duration of the installation fixed the problem for me.
So if you see this problem, try disabling your anti-virus.
The answer in the following page helpped me.
http://forums.enterprisedb.com/posts/list/3040.page
run-> regedit and take backup of registry using export
HKEY_LOCAL_MACHINE->SOFTWARE->Classes->CLSID->B54F3741-5B07-11cf-A4B0-00AA004A55E8} -> InprocServer32
Modify registry entry with new value as C:\Windows\System32\vbscript.dll
In fact, I found there are 3 entries of HKEY_LOCAL_MACHINE->SOFTWARE->Classes->CLSID->B54F3741-5B07-11cf-A4B0-00AA004A55E8}, and set the first one as above, it works.
If anyone else is searching for information on this and doesn't have any luck here, you might want to look at:
http://wiki.postgresql.org/wiki/Troubleshooting_Installation
For follow-ups to the mailing list please read:
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
Well, in my case nothing worked, and disabling McAffee needed a special ticket with my company's security team to actually do... so I installed using the binaries, by following this guide Helpful Guide.
In summary, download the binary from here, unzip it, go inside the pgsql folder, create log and data directories in there, and then open a command prompt, navigate to where the pgsql\bin folder is, and run initdb -U postgres -A password -E utf8 -W -D POSTGRESQL_ROOT\data
You can start and stop the server by running
"POSTGRESQL_ROOT/bin/pg_ctl" -D "POSTGRESQL_ROOT/data" -l "POSTGRESQL_ROOT/log/pgsql.log" start
and
"POSTGRESQL_ROOT/bin/pg_ctl" -D "POSTGRESQL_ROOT/data" -l "POSTGRESQL_ROOT/log/pgsql.log" stop
where POSTGRESQL_ROOT is the full path to the pgsql folder.
All the above did not work for me. I was getting an error like:
Script output:
CScript Error: Windows Script Host access is disabled on this machine. Contact your administrator for details.
so after a couple of googling i found the solution:
Navigate to the following key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Script Host\Settings
In the right panel, you will see Enabled. If you see the entry 0, it means that the Windows Script Host access is disabled on your Windows machine.
Double Click on it and give it Value Data 1 to enable it.
A value of 1 will enable Windows Script Host
A value of 0 will disable Windows Script Host.
for windows 10 navigate to
HKEY_CURRENT_USER\Software\Microsoft\Windows Script Host\Settings
To prevent further problems you should also exclude the data directory (where Postgres puts its data) from being scanned by your virus-scanner
In my case it was another application that caused the problem. Not Notepad++. To others who encounter this problem, you can diagnose it by first deleting all files in C:\Documents and Settings\UserName\Local Settings\Temp so that you'll be able to find the bitrock_installer.log easily when you try installing postgresql again and view the instructions in it. Changing the (Default) key in the HKEY_CLASSES_ROOT, .vbs section of the registry to VBSFile solved it.
I had this issue when trying to install the 32 bit version on Windows 7 64 bit.
Trying the install kit for 64 bit presented no errors, but the solutions presented by others are also valid.
In my case I've downloded McAfee removal tool
MCPR (McAfee Consumer Product Removal)
which cleaned up some tailings after McAfee uninstallation.
Some registry entries which previously had InprocServer32 values like 'c:\program files\common files\mcafee\systemcore\...' changed back to its original values:
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32\(default) = vbscript.dll
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32\(default) = C:\Windows\SysWow64\vbscript.dll
After that I successfully installed PostgreSQL 9.3
it happens when Notepad++ associates .vbs file types.
you can open notepad++ -> Preferences -> fileAssociation
Remove the .vbs from the registered exts.
Close the notepad++. Try installing Postgres again.
In my case Changing the (Default) key in the HKEY_CLASSES_ROOT, .vbs section of the registry to VBSFile solved it. BlueFish is grab .vbs file association.
In the temp directory, my bitrock_installer.log file had the following:
Executing cscript //NoLogo "C:\Users\MyUser\Local
Settings\postgresql_installer_1b4eec8be6\prerun_checks.vbs"
Script exit code: 1
Script output:
Input Error: Can not find script file "C:\Users\MyUser\Local
Settings\postgresql_installer_1b4eec8be6\prerun_checks.vbs".
Turns out that Windows has a symlink between the following directories:
C:\Users\cpetrie\Local Settings\Temp
C:\Users\cpetrie\AppData\Local\Temp
For some reason my "TMP" and "TEMP" user variables were referencing the "Local Settings" path instead of the "AppData" path. Changing this fixed my install issue.
My problem was Smad-Av which disables Windows Scripts from running,
Only after going through this thread i remembered.
I just right clicked the Smad-Av icon and selected Allow Windows-Script & Office-Macro (Permanent).
I had the same problem with installing PostgreSQL (Unable to write in TEMP environment variable path), the problem was in Windows Script Host which was disabled (check the log file to see if this is your problem). enable it with register editor (run-->regedit) at this location Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows Script Host\Settings by setting its value at 1
For more details check this web link: http://1stopit.blogspot.com/2011/01/postgresql-83-and-84-fails-to-install.html
I had the same problem in Windows 10 and the culprit was the OS's permission, or rather the lack thereof, on allowing the executable to write on the User dedicated Temp folder.
Solved it by following my gut and changing the User Temp folder to the same with the system's : Win + Pause/Break to have the Computer Properties window appear (you can do that manually by right-click on Computer icon on Desktop -> Properties) -> click on Advanced System Settings on the panel on the left -> click on Environment Variables and
under "System variables" - Variables, find the TEMP and TMP ones and copy their paths. Then, under "User variables for Administrator" - Variables, find the TEMP and TMP ones and paste the paths. It's most always "C:\Windows\TEMP" anyways ;)
There's this site I read : https://www.askvg.com/where-does-windows-store-temporary-files-and-how-to-change-temp-folder-location/
search for "Registery Editor" and run it.
choose HKEY_CURRENT_USER => SOFTWARE => Microsoft => Windows script host => Setting (Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows Script Host\Settings)
open "Enabled" and change value data to "1".(you will find it with a vlaue of 0).
Happy coding!
Check the log in the system's TEMP directory (provided the installer is able to write into it).
There's lot of information about the errors.
My issue was that VBS files were associated with a text editor (probably the anti virus software is the culprit) .
Here you can find some reg edit scripts to revert to the default behaviour:
http://www.nilpo.com/2009/07/windows-xp/restoring-vbs-vbscript-script-file-file-associations/#more-107
Cheers
My solution is similiar to #5, with an Explantion of how and why McAfee ruins your vbscript registration.
Apparently, when I had McAfee antivirus software on my computer, it bashed the vbscript.dll registration that Windows Scripting Host needs to run .VBS files.
In the exported .REG file:
[HKEY_CLASSES_ROOT\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32]
#="C:\Program Files\Common Files\McAfee\SystemCore\ScriptSn.20120327211246.dll"
That SHOULD be changed back to "C:\Windows\System32\vbscript.dll" now.
McAfee apparently installs a DLL that hijacks the vbscript.dll in order to try to protect bad scripts from running. When I uninstalled McAfee in favor of Microsoft
Security Essentials, McAfee did not restore the registry paths ("not
my problem"), and the McAfee DLL, of course, was removed from the location during uninstall, so the vbscript.dll registration in fact pointed to NOWHERE and NOTHING.
There has to be a better way to write Antivirus software so that it doesn't disable the user's operating system when it is uninstalled, or when features
are turned off, or replace registration. See the following:
https://kc.mcafee.com/corporate/index?page=content&id=KB71660
I have a 64-bit OS. The registry path was changed in a number of locations.
The regular class ID should point to the "C:\Windows\System32\vbscript.dll" 64-bit file.
The "Wow6432Node" registry paths should point to the "C:\Windows\SysWOW64\vbscript.dll" 32-bit file.
Yes, the 64-bits are in the "32" folder and the 32-bits are in the "SysWOW64" folder. Microsoft didn't want to change the name of the main "System32" execution folder when it migrated to 64-bits.
HKEY_CLASSES_ROOT\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}
C:\Windows\System32\vbscript.dll
HKEY_CLASSES_ROOT\Wow6432Node\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}
C:\Windows\SysWOW64\vbscript.dll
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}
C:\Windows\System32\vbscript.dll
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}
C:\Windows\SysWOW64\vbscript.dll
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}
C:\Windows\SysWOW64\vbscript.dll
Before you start messing with the registry, check if WSH is actually disabled or not. To do that run wscript.exe in the DOS box.
If you see a dialog box called "Windows Script Host Settings", WSH is enabled, and your problem with PostgreSQL installation must be related to something else.
If you get an error box that says "Windows Script Host access is disabled on this machine. Contact your administrator for details", WSH is disabled, and your problem with PostgreSQL installation may be related to it (or may be not).
For me, my problem was related to Windows script. I resolved this by right-clicking on smadav icon in the hidden icons in the task bar and checked "Allow Windows-script and Office-Macro (Permanent)". Then double click on the PostgreSQL setup again.
First go to registry Editor then choose HKEY_CURRENT_USER > software > Microsoft > Windows script host > setting > default > add value data to 1 and click Ok. done!
After disabling Smad Av, it still did not work. So, I right clicked on the Smad Av tray icon and I selected 'Allow Windows-Script & Office-Macro (Permanent)' and it worked.