I just opened a PowerShell console on Windows 11, and after running any command, it showed a dialog with a message like:
/hostfxr.dll is either not designed to run on Windows is it contains and error
Any ideas?
Just download the last hostfxr.dll from this website and copy it to this directory:
C:\Program Files\PowerShell\7
If you are stuck at running Apache Pig on windows due to an error like
hadoop-2.4.0\bin\hadoop-config.cmd' is not recognized as an internal or external command,
operable program or batch file.
though you are having Hadoop running perfectly on windows
Answer, which was originally added by the asker inside the quesiton.
These steps may help you.
Troubleshooting steps
open the file pig.cmd in any editor like notpad / notepad++
look for the line set HADOOP_BIN_PATH=%HADOOP_HOME%\bin
replace this with set HADOOP_BIN_PATH=%HADOOP_HOME%\libexec
What we did was that hadoop-config.cmd file was not being found by pig so we pointed it with the correct one. You may first find where the hadoop-config.cmd file is and replace it with appropriate path. This was what my hadoop-2.4.0 was having.
I'm using tscon.exe to unlock a remote machine locally before I can run automation tests. When I run my command via RDC it works as expected and unlocks the remote machine locally:
C:>tscon.exe %sessionname% /dest:console
But I need this to run as my first TeamCity build step. Doing so either as a direct TeamCity Custom Script or starting a .bat file, both return the error:
[16:50:22][Step 1/11] in directory: C:\BuildAgent\work\e4249c2d6a4e9e8d
[16:50:22][Step 1/11] 'tscon.exe' is not recognized as an internal or external command,
Why is tscon.exe not recognised when used via TeamCity?
I just had same issue and moving the exe out of System32 is not an option for me.So I have to dig deeper.
Turns out the problem is not Teamcity. It's windows.
"The windows filesystem redirection forces 32-bit application attempts to be installed into or accessed from %windir%\System32, been intercepted and get redirected or re-pointed to %windir%\SysWOW64 instead."
The solution is to use an alias name ( %windir%\Sysnative ) for that directory which windows will not redirected.
Try this :
C:\Windows\Sysnative\tscon.exe %sessionname% /dest:console
For more detailed Reference : http://www.tipandtrick.net/how-to-suppress-and-bypass-system32-file-system-redirect-to-syswow64-folder-with-sysnative/
Here is the solution:
Copy tscon.exe to any location other than %windir%\System32\
i.e. C:\TeamCity\tscon.exe
Add TC build step as below (ensure to include Working Dir):
Now the remote machine will login locally before completing the TC steps
On Windows 7 Ultimate, I have a batch file that enables and turns on services related to vmWare workstation. Since the batch file is in the path, I can execute it from the command line in any directory, it works fine.
However when I try to run the batch file from the Windows Explorer (double click) or from a shortcut to the batch file it does not work; for example a typical SC command generates this error:
**
C:\Batch>sc config VMwareHostd start= demand [SC]
ChangeServiceConfig FAILED 5:
Access is denied.
**
Any ideas?
Thank you in advance.
I had enabled telnet client feature on Windows 2008, and tried to launch it from a Perl script:
perl -e "system('c:\windows\system32\telnet localhost')"
Then I got an error like this:
'c:\windows\system32\telnet' is not recognized as an internal or external command,
operable program or batch file.
I could run it from 'cmd' terminal, or, if I copy the telnet.exe to local dir, it could be launched. I examined the permissions of telnet.exe under c:\windows\system32, no special finding.
Could anybody help me on this case? Thanks a lot!
I ran into the exact same problem recently, trying to launch telnet and the rdp client programmatically. The problem is related to an aspect of windows "design" called file system redirection:
"Windows on Windows 64-bit (WOW64) provides file system redirection. In a 64-bit version of Windows Server 2003 or of Windows XP, the %WinDir%\System32 folder is reserved for 64-bit applications. When a 32-bit application tries to access the System32 folder, access is redirected to the following folder: %WinDir%\SysWOW64. By default, file system redirection is enabled."
http://www.codeproject.com/tips/55290/Disabling-Windows-file-system-redirection-on-a-CFi.aspx
I think you have to specify the full name of the program, that is telnet.exe. But you'd be better off using Net::Telnet module or something like Expect.pm that handles interactive sessions programmatically.
hi you are using Perl, so i was wondering why you don't use Net::Telnet, instead of the telnet.exe of windows, which AFAIK is not friendly for programming.
On my computer following code works (Windows 7):
$telnet = $ENV{'WINDIR'} . '\system32\telnet.exe';
system("$telnet 192.168.1.1");
It must be either a) permissions b) incorrect path, c) you need .exe at the end or d) you need to capitalise the "c:"
You might want to verify under what account Perl execute and check if that account has permissions to run executables like telnet.
Just to verify the theory, I'd run Perl under a high privileged account (like admin) to check if it runs telnet and then tweak the account it is running under.
Hope this helps!
Read about console host.
ConHost represents a permanent change in the way that console application I/O is handled.
See also a related post on SysInternals forums.
I do not have access to any Windows Server 2008 machines right now, so I cannot test this, but can you check what happens when you run wperl -e "system('c:\windows\system32\telnet localhost')" from the equivalent of Start -> Run on that OS.
The answer is: using sysnative instead of system32, because the 32-bits application is not allowed to have access to the system32 directory (64-bit application). By using this alias sysnative it wil work.