I am using Windows 7 and have upgraded to Windows Management Framework 3.0, which includes PowerShell 3. Within the past week or so, I have started getting an error upon starting PowerShell that prevents it from starting until there is a CD in my computer's drive (any CD will do). The only fix I have found so far—and this is only a temporary fix—is to completely uninstall and reinstall the Management Framework. This works until I use the CD drive for something, then PowerShell starts acting up again. The error dialog reads: There is no disk in the drive. Please insert a disk into drive D:.
Does anybody have any suggestions for what might be going on here? I see two possible problems related to configuration settings, but still need guidance about what/where to check and verify:
PowerShell is configured somewhere to check certain drives on startup, and isn't responding well to an empty CD drive
PowerShell is actually trying to open to some path on D:\. I'm pretty sure this is not the problem, since it opens to my %USERPROFILE% when there is a CD in the drive, but of course I could be missing something
Of course, I'm sure there are plenty of other possibilities I haven't considered
Any thoughts on possible fixes? I'd like not to have to uninstall and reinstall the Management Framework every time I use my CD drive!
EDIT: Additional details below copied from my responses to various comments
I can recreate the error by launching PowerShell in multiple ways. Shortcut is one. Starting it from a Command Prompt (cmd.exe) is another. Even trying to call a PowerShell script from a Command Prompt using something like PowerShell -ExecutionPolicy RemoteSigned -File script.ps1 produces the error, and so does PowerShell /?.
I don't see anything pointing to D:\ in $env:PATH and $env:HOMEDRIVE is not set to D:. %windir% is set to C:\Windows, %SystemDrive% is set to C:, and %SystemRoot% is set to C:\Windows.
Re-assigning the CD drive to a different letter resolves the problem, but this isn't a solution because it addresses the symptom and not the underlying cause (whatever that is).
When everything else fails, I can still start PowerShell from Cygwin
Process Monitor (linked below) is showing an attempt to read a non-existant registry entry HKCU\Software\Classes\Local Settings\MuiCache\5E6\52C64B7E\#D:\Windows\system32\AccessibilityCpl.dll,-10. Whatever mechanism is causing that bad read is likely also causing the error dialog. Something must be programmatically changing the system drive within PowerShell itself.
Further thoughts and suggestions are appreciated.
When Powershell first launches, it checks designated folders to import modules. I would take a good look at these. The default var is $env:PSModulePath and acts much like the standard $env:Path var. I would review that path and see if there are any references to the D: drive there.
MSDN - Windows PowerShell Modules
Are you installing .net from the DVD drive? Maybe downloading a fresh copy from MS would clear this up. MS .Net Framework 3.0 is very old, it is actualy designated for Server 2003 or WinXP. Is there a reason you are using it instead of 3.5, 4 or 4.5.1?
Related
I am trying to Run setup.exe as part of Oracle 19c installation on windows 10.
I have downloaded the zip file and extracted it in a folder inside C drive.
When I try to run setup.exe by right click and run as administrator option, a command prompt just flashes for a split of a second and nothings starts after that.
I have found the solution:
After extraction, rename the extracted directory to db_home
Move the db_home directory to the root of your Hard Drive ( in my case its C:\db_home )
run setup.exe as an administrator.
You will see a cmd window pop up and then the red window with the Oracle symbol in it.
Do NOT skip step 2nd step as that is how I was finally able to get it to install.
This also worked with 19c.
I also faced the problem. After seeing this thread, in a while, I figured it out. Apparently, keeping the db_home folder inside a folder that has space in its name caused me the same issue.
I had the same problem and read something about problems with extremely long paths in packages and using the native Windows unzip utility. I unzipped the package using 7-zip instead and it solved the problem.
I was trying to install from d partition and does not work. Then I just move all the installation folder to c partition and it works fine.
I'm an Oracle DBA and I don't know when the change happened or what the source of issue is, but when installing the Oracle client you can no longer have a space " " in the path for the Oracle setup.exe file.
It doesn't matter what utility extracted the files or what drive or path is used (except there is and always has been an issue with very long path names) - it just cannot have a space in the path.
I hope this helps.
This issue has a simple solution:
When we run the Setup file we see a flash CMD in the background...
Your System Environment variable path(DB home) has Space in it.
It should be no space(db_home)
This personally works for me to install.
I updated my cygwin using the setup-x86_64.exe tool (version 2.873) on Windows 7.
I needed to install some additional packages (mostly zip/unzip etc).
Since then, I am getting the following errors when I try to run the Cygwin Terminal (the shortcut points to C:\cygwin64\bin\mintty.exe -i /Cygwin-Terminal.ico -):
Error: could not fork child process: Resource temporarily unavailable.
DLL rebasing may be required. See 'rebaseall / rebase --help'.
I searched online how to run the rebaseall command they advise in the message. Essentially the recommendation was to start cygwin/bin/dash.exe and run:
bin/rebaseall
I did that a few times, I also used the -v comment, and no errors come back. Still I can't start cygwin.
I also tried running cygwin-x/XWin-server nothing happens.
I looked at the setup logs in cygwin/var/log/setup.log I can't see any error.
I tried to run the setup program a few more times reinstalling some of the packages I already had, that didn't help neither.
Any ideas how can I get that to work?
Here is the fix.
Go to you Windows Defender Security Center settings
Click on App & Browser Control
At the bottom click on the "Exploit Protection Settings" link
Go to "Program Settings" and click on the "Add program to
customize" -> "Choose exact file path"
Navigate to "C:\Program Files\Git\usr\bin\sh.exe" and add it
Override and turn off the following: Mandatory ASLR, Randomize memory allocations (Bottom-up ASLR)
Click "Apply" and now everything should work fine.
Also add these other binaries from the same folder: expr.exe, uname.exe, grep.exe, rm.exe
Good luck,
Gabriel
One of my colleagues has similar errors when openening the terminal from SourceTree (Mingw32), and also got errors when trying to pull, rebase, etc (anything not local). He solved it by uninstalling Sourcetree, using CCleaner to clean his registries (not sure if this was required), rebooted and installed Sourcetree again.
I know this is slightly different from the problem described by the OP, but it might still be solvable by un/re-installing and cleaning of registries, and this might also help future people finding this question with the Sourcetree issue (like I did).
Edit:
Another colleague had the issue as well, and he managed to fix it merely with a restart without any un/re-installation or using CCleaner.
I've been suffering similar problems a lot recently. I've been unable to determine the cause, whether it's due to a recent Windows7 patch or an update in the latest cygwin. I'm in a tightly controlled corporate environment with only limited elevated rights, a lot of anti-malware and encrypted drives. I'm using 32-bit Cygwin at present.
Issues for me began after I installed Git and Git-Svn packages, which required Perl and upgraded various other Cygwin packages as well.
Rebasing using rebase-trigger or rebaseall did not solve the issue for me. Neither did re-installing and setup repeatedly raised errors in the post-install pahse when trying to do the rebase itself.
My first success was by downgrading Perl to the previous version, ie. down to 5.22.1.2 from 5.22.2.1. After a couple of weeks the error returned, perhaps after a compulsory windows update and reboot.
My latest success has been achieved by ignoring the dash/rebaseall script and running rebase.exe directly as follows:-
Create a file which lists all cygwin .dlls in the /bin directory except cygwin1.dll and cyglsa.dll ie.
$ cd /bin
$ ls -1 *.dll | egrep -v '(cygwin1|cyglsa).*\.dll' >rebasedlls.txt
Close all cygwin terminals, if you have any services running which use cygwin ensure that those are stopped also. Check TaskManager and kill processes if necessary.
Open a cmd.exe window (it may help to use whatever elevated rights you can muster), change to the windows path of your cygwin /bin directory (ie. the windows directory of cygpath -wa /bin).
Use rebase.exe directly to find the base address of the cygwin1.dll file:
C:\apps\cygwin\bin> rebase.exe --info cygwin1.dll
/usr/bin/cygwin1.dll base 0x61000000 size 0x00500000
Using that base address and the size as a guide I chose the next whole value up as my rebase base address, 0x62000000. No particular reason for this, just a hunch. (The rebaseall script uses 0x70000000).
Use rebase.exe to fix all the .dlls listed in the file from step (1):
C:\apps\cygwin\bin> rebase -b 0x62000000 -4 -n -v -t -T rebasedlls.txt
So far, so good, my Cygwin is back to a working state again.
From https://chromium.googlesource.com/chromium/src/+/master/docs/cygwin_dll_remapping_failure.md
Handling repeated failures of rebaseall to allow cygwin remaps
Sometimes DLLs over which cygwin has no control get mapped into cygwin
processes at locations that cygwin has chosen for its libraries.
This has been seen primarily with anti-virus DLLs. When this occurs,
cygwin must be instructed during the rebase to avoid the area of
memory where that DLL is mapped.
Background
Some background for this is available on
http://www.dont-panic.cc/capi/2007/10/29/git-svn-fails-with-fatal-error-unable-to-remap/
Because of unix fork semantics (presumably), cygwin libraries must be
mapped in the same location in both parent and child of a fork. All
cygwin libraries have hints in them as to where they should be mapped
in a processes address space; if those hints are followed, each
library will be mapped in the same location in both address spaces.
However, Windows is perfectly happy mapping a DLL anywhere in the
address space; the hint is not considered controlling. The remapping
error occurs when a cygwin process starts and one of its libraries
cannot be mapped to the location specified by its hint.
/usr/bin/rebaseall changes the DLL hints for all of the cygwin
libraries so that there are no inter-library conflicts; it does this
by choosing a contiguous but not overlapping library layout starting
at a base address and working down. This process makes sure there are
no intra-cygwin conflicts, but cannot deal with conflicts with
external DLLs that are in cygwin process address spaces
(e.g. anti-virus DLLs).
To handle this case, you need to figure out what the problematic
non-cygwin library is, where it is in the address space, and do the
rebase all so that no cygwin hints map libraries to that location.
Details
Download the ListDLLs executable from
sysinternals
Run it as administrator while some cygwin commands are running.
Scan the output for the cygwin process (identifiable by the command) and for
DLLs in that process that do not look like cygwin DLLs (like an AV). Note
the location of those libraries (there will usually only be the one).
Pick an address space location lower than its starting address.
Quit all cygwin processes.
Run a windows command shell as administrator
cd in \cygwin\bin
Run ash /usr/bin/rebaseall -b <base address> (This command can also take a
-v flag if you want to see the DLL layout.)
That should fix the problem.
Failed rebaseall
If you pick a base address that is too low, you may end up with a broken cygwin
install. You can reinstall it by running cygwin's setup.exe again, and on the
package selection page, clicking the "All" entry to Reinstall. You may have to
do this twice, as you may get errors on the first reinstall pass.
I have Administrator access to my PC. For me the solution to this was to run the Cygwin session as Administrator -- right the icon, run as administrator, as shown here:
After running as Administrator the first time, new Cygwin sessions started up without hassle.
There is a rebase utility that triggers the rebase as post-setup phase.
From dash or bash:
/usr/bin/rebase-trigger full
close all process and run again setup-x86_64.exe.
uninstall it,
and install the software for 32-bit.
I restarted 3 times, and then it was fine. wtf Windows 7
This exact same error message has various causes, not all of them related to setup-x86_64.exe, although I have seen it in that context as well. But if rebaseall didn't fix your problem, here's a suggestion that might work.
In the case I saw this morning, it turned out to have been caused by having a couple of processes that continued to run after I exited the mintty terminal emulator. My hunch is that these zombie processes prevent the console from being recycled. In my case, the two processes were determined experimentally, by reviewing a list of running processes for stray processes that are no longer needed. I found the two processes that were blocking me by reviewing the list of running tasks.
C:\WINDOWS\system32>tasklist | grep Console
CobraWinLDTP.exe 31844 Console 1 43,600 K
geckodriver.exe 52640 Console 1 32,164 K
C:\WINDOWS\system32>taskkill /F /PID 31844
SUCCESS: The process with PID 31844 has been terminated.
C:\WINDOWS\system32>taskkill /F /PID 52640
SUCCESS: The process with PID 52640 has been terminated.
I saw on some other stackoverflow questions that git is often the zombie process that causes this symptom (for some users). Unfortunately, any residual process that survives after your console session is closed can cause this problem, so you have to experiment.
Go to The Task manager
Kill 'Git for Windows' process
Reopen your git bash
It seems that all is working fine.
NOTE: In case you don't find 'Git for Windows' process and still have to face the same just kill 'Node.js: Server-side JavaScript' process instead
If you have turned Force randomization for images (Mandatory ASLR) on in Exploit protection of Windows Security, then you can turn it off by selecting Use default (Off) to address this issue.
My instance of this problem was also related to having turned on 'force randomization for images' in the Windows Security exploit protection settings.
After you change the setting back to the default off position and reset, you will have to run Git as an administrator in order to effect directory changes which apparently require elevated permission.
I wasn't able to determine a way to allow that setting to be turned on and not get this issue with Git though I played around with it for a while unsuccessfully.
Turning even optional security features off to get a single program working seems like a last resort option to me. However, this isn't just any program either.
I have GNU Emacs 23.4 installed (or, rather, unzipped) into C:\Program Files (x86)\emacs-23.4 on my Win7 64-bit system.
It works fine except that when logged in as a non-administrative user I cannot associate files with the GNU Emacs executeables (I've tried to associate a given file type with runemacs.exe and with emacsclientw.exe). I can browse to the file in the associate dialog, but when I hit "open" it's just ignored.
It works totally fine when I'm logged in as an admin user. (And it worked fine in XP.)
I have found the following: http://answers.microsoft.com/en-us/windows/forum/windows_7-windows_programs/in-windows-7-how-do-i-change-the-open-with/c4a2ad7e-125c-4526-be20-c8f24f18fbfc but I'd prefer to not have to fiddle with registry entries if there's another way to accomplish this.
Any ideas?
If you had a previous version of emacs installed then windows will have associated the name emacsclientw.exe and runemacs.exe with the older version path. To successfully use a new version of emacs you have to remove those associations from the registry with regedit.exe.
Remove the entries:
HKEY_CLASSES_ROOT\Applications\emacsclientw.exe
HKEY_CLASSES_ROOT\Applications\runemacs.exe
Please also see
http://answers.microsoft.com/en-us/windows/forum/windows_7-windows_programs/how-do-i-remove-programs-from-the-other-programs/73a34fc6-b968-429f-9e5e-a0873d67eed9?msgId=1946ffef-cf76-49c6-adb8-0850e1c8610d
I've had the same problem and I've found that the registry entry has to be
emacs-path\bin\emacsclientw -n "%1"
After many attempts to make the GNU Emacs Windows build work to my satisfaction, I always come back to the patched EmacsW32 build. Among other things, it provides an installer that adds file associations and other shell extensions. I've found that it always handles the "Open With" problem correctly. Unfortunately, the latest patched build is of Emacs 23.1.
Same problem trying to associate Allegro Free Physical Viewer rev 16.6 to .brd files.
It turns out that the registry key had the wrong path to the application. I ran regedit navigated to:
HKEY_CLASSES_ROOT > Applications > allegro_free_viewer > shell > open > command
copied out the path and tried that in a CMD window and got path not found (bad path).
I navigated a explore window to the path of the application and copied that path into the registry "command" value, closed regedit, and it worked.
Just getting started with PowerShell. I was running DOS .bat files in my post build events in VS and wanted to graduate up to PowerShell. Bat files were easy...CALL something.bat. I tried to do that with a PowerShell ps1 file and my trial-and-erroring got me to the following (first thing that worked...tried all the simple things first, obviously):
powershell -command "& {(powershell '$(ProjectDir)test.ps1')}"
Is there a shorthand version of this? I think the only thing that really bothers me is the redundant calls to the powershell executable, but that's probably only required because .ps1 files open in notepad by default on my machine (and I should keep the redundancy for deployment on other systems so I'm not reliant on the default program for a file type). Anyway, if there's unnecessary redundancy here, I'd love to know.
I'm very new to PowerShell, so any related insight is always appreciated.
I've used PowerShell as a post-build event in the past; now I lean towards using psake
(super simple build system) or just running a raw PowerShell script. Post-build events get messy, are inflexible, and have few advantages over doing the same thing in a build script.
EDIT: If you are still interested in using a post-build script, I've answered the question before here
According to the MSN, this should work nice:
powershell.exe "$(ProjectDir)test.ps1"
Edit: Found this
powershell.exe "& ""$(ProjectDir)test.ps1"""
I didn't check any MSDN, it simply works:
powershell $(ProjectDir)test.ps1
Btw. don't forget to set run privileges for BOTH versions of PowerShell -- 32-bit and 64-bit.
I was sort of happy with the elegant powershell $(ProjectDir) solution detailed here, but I ran into problems when starting/stopping IIS App Pools via WebAdministration's Start-WebAppPool and Stop-WebAppPool
I had better success with:
%WINDIR%\SysNative\WindowsPowerShell\v1.0\powershell.exe
i.e.
%WINDIR%\SysNative\WindowsPowerShell\v1.0\powershell.exe -Command "$(ProjectDir)Powershell\Stop-AppPool.ps1"
The reason turned out to be mixing of architectures, as detailed here (in the section "Using Windows PowerShell Scripts to Automate Tasks in Visual Studio"):
It's important that you use the virtual path of %WINDIR%\SysNative and
not the actual path of C:\Windows\System32. The reason for this is
that Visual Studio 2010 is a 32-bit application that needs to call the
64-bit version of powershell.exe to successfully load the
Microsoft.SharePoint.Powershell snap-in.
I am quantitatively studying various metrics associated with automated tests. Chrome seems to have a reasonable set, so I wanted to add it to my data set. I downloaded the Chrome source code and tried to build it with VisualStudio but got several hundred errors--types not defined, identifiers not defined, etc. Has anyone out there succeeded in building Chrome under Windows? Are there tricks I need to know?
From the Chromium dev page:
Compilation failures
Some common things to think about when you have weird compilation failures:
Make sure you have SP1 for Visual Studio 2005. It's required. Really.
Sometimes Visual Studio does the wrong thing when building Chromium and gets stuck on a bogus error. A good indication of this is if it is only failing for one person but others (including the Buildbots) are not complaining. To resolve this, try the following steps:
Close Visual Studio.
Sync to the tip of tree and ensure there are no conflicts ("svn st" should not show any "C"s in front of files that you've changed).
If there were conflicts, sync again after resolving them.
Manually erase the output directory (chrome\Debug and chrome\Release. Using the command line, you can use "erase /S /Q Debug Release" from the chrome directory to do this, or "rm -rf Debug Release" if you have Unix-like tools installed.
Restart Visual Studio and open the Chromium solution.
Rebuild the solution.
If it still doesn't work, repeating this process probably won't help.
chrome_kjs.sln tempfile problems
If, while building JavaScriptCore, you see errors like:
3>Error in tempfile() using /tmp/dftables-XXXXXXXX.in: Parent directory (/tmp/) is not writable
3> at /cygdrive/c/b/slave/WEBKIT~1/build/webkit/third_party/JavaScriptCore/pcre/dftables line 236
3>make: *** [chartables.c] Error 255
...it's because the Cygwin installation included in the Chromium source is having trouble mapping the NT ACL to POSIX permissions. This seems to happen when Chromium is checked out into a directory for which Cygwin can't figure out the permissions in the first place, possibly when the directory is created from within a Cygwin environment before running mkpasswd. Cygwin then imposes its own access control, which is incorrectly restrictive. As a workaround, do one of the following:
Edit the NT permissions on third_party\cygwin\tmp to allow Modify and Write actions for Everyone and machine\Users. Cygwin is able to figure this out. Or,
Figure out what went wrong with your checkout and try again - try doing the checkout from cmd instead of from a Cygwin shell, then verify that the permissions aren't completely blank in your Cygwin installation. Or,
Bypass Cygwin's access control (NT's will still be in effect) by editing webkit\build\JavaScriptCore\prebuild.bat and webkit\build\WebCore\prebuild.bat to include the following line before invoking anything that uses Cygwin:
set CYGWIN=nontsec
Only one of these solutions should be needed.