I wrote a wpf application to create a screensaver, i rename the exe to scr. i am able to run it from bin directory or if i copy it to d directory.
but when copy it to C:\Windows\System32 and try to run it from cmd prompt or I launch it from Control Panel > All Control Panel Items > Personalization > Screen Saver it thorws an exception, click here for screen shot.
I am working on windows 8 machine.
Thanks
The problem is that the screensaver was compiled for 32bit cpu. Only 64bit exes are allowed in the %WINDIR%\System32 folder on a 64bit OS. Which in fact, i was using Windows7 64bit.
The correct place to put 32bit screensavers is in %WINDIR%\SysWOW64 or compile using 'AnyCPU' option in Visual Studio then you can install into the %WINDIR%\System32 for all.
Related
I updated a vb windows forms application using visual studio 2015. I need to install this on a windows xp machine.
I updated my application to run using .net framework 4.0, the same as the one installed in the xp machine.
When I tried to install it the first time, it asked me to restart the machine, which I did. after restarting it gave me the error that installation is incomplete.
I have been researching all morning on how to fix it, i tried the dpca.dll solution, i tried restarting the windows installer service, i used msiexec to view the logs, and now it gives me the error that a dll required for this install to complete could not be run. I have no idea which dll, it doesn't say.
My application is fine. It builds and installs beautifully on windows 7 and above.
Please help me before I smash the windows xp machine into pieces.
I came across a comment that i can run the executable itself, just needed to copy all the dll files and put it in the same folder as the executable. So I just copied the whole folder and run the exe on the xp machine and it works.
I am running an assembly jar file in command prompt and getting the exception below. And resulting in termination.
Uncaught error from thread [ccp-akka.persistence.dispatchers.default-plugin-dispatcher-23] shutting down JVM since 'akka.jvm-exit-on-fatal-error' is enabled for ActorSystem[ccp]
There is nothing else running in my windows machine while this.
No code access is there except a jar file.
What might be the issue, i tried restarting the machine a couple of times.
Looks like the issue is only with my machine since it is running fine in all other machines. Even i cross checked all the environmental variables.
Attached the screenshot.
What it says that there is a missing binary dependency, leveldbjni, which interfaces with native/platform specific version of leveldb.
Adding leveldbjni-all to your dependencies as described in the docs (http://doc.akka.io/docs/akka/2.5.0/scala/persistence.html#id8) should solve that, if it doesn't then maybe the platform is unsupported (which seems weird, the leveldbjni homepage lists both win32 and win64 as supported - https://github.com/fusesource/leveldbjni)
Step1: Go To "C:\Users\asaini75" and Delete already existing folder ".datastax_studio"
Step2: Go To "C:\Users\asaini75\Downloads\datastax-studio-6.0.0\bin" and click on "server" windows batch file and Wait until you see the below message on your command prompt.
Step3: Go To browser and hit the URL "http://localhost:9091". You will below the home page.
Step4: Add connection and Notebook. it will work perfectly fine.
I installed the Microsoft Visual C++ 2010 Redistributable for my windows machine, that solved my issue. Reference.
The Microsoft Visual C++ 2010 Redistributable Package installs runtime components of Visual C++ Libraries required to run applications developed with Visual C++ on a computer that does not have Visual C++ 2010 installed.
Download link here (x64).
I've run regsvr32 "name.dll" from system32 and SysWOW64 and both say it was able to load .dll but return error code 0X80004005 (access denied). I've tried running it in an elevated command prompt (right click, run as administrator) and that still returns the same error code. I've repaired the registry and restarted the computer, same error code. Any other suggestions?
The problem was that it was a Visual Fox Pro .dll and the VFP runtime files had to be moved into the SysWOW64 folder before registering the .dll.
I created a dll file built (Project:win32 app, ATL and COM object using Visual studio 2008) in 32 bit. In win 7 32 bit OS, After registering my dll i'm getting "ABC" option in context menu(on right click). Now i move to win 7 64 bit OS. Dll loaded successfully, but i'm not getting "ABC" option on right click(in context menu). Can anyone please point me where i went wrong or any suggestions ?
Note: Right click on Folder gives "ABC" option.
A shell extension compiled for 32bit will run only in a 32bit process. The Windows Explorer of a 64bit Windows is a 64bit process, so it requires a 64bit shell extension.
If a 32bit application would use the fileopen dialog (on a 64bit Windows), the dialog would require a 32bit shell extension. So it's recommended that you install your extension like that:
Win32: 32bit Shell Extension
Win64: 64bit and 32bit Shell Extension
To do this, you have to give different GUIDS to the 32bit / 64bit shell extension. Hope that makes it a bit more clear.
Edit: As Raymond suggested, it seems that you can use the same GUID for both extensions.
I'm using this code in XP 32-bit OS to get the %windir%\windows\system32 folder path.
sysFolderPath = Environment.GetFolderPath(Environment.SpecialFolder.System)
What I want to know is that will this same code return the %windir%\windows\syswow64 folder when used in Windows 7 (64/32-bit)?
It will return c:\windows\system32, even in a 32-bit program that runs on the 64-bit version of Windows. Do not fix this, it doesn't need fixing. Because when you use that path, Windows will automatically remap it to c:\windows\syswow64. The file system redirector takes care of it.
I tried on my Windows7 box with .NET 4.0
This code:
Console.WriteLine(Environment.GetFolderPath(Environment.SpecialFolder.System));
Console.WriteLine(Environment.GetFolderPath(Environment.SpecialFolder.SystemX86));
Prints the following from both 32- and 64-bit process:
C:\Windows\system32
C:\Windows\SysWOW64
Nope. On my Windows 7 64-bit box, targeting x64:
C:\Windows\system32