I developed a out process COM server, test.exe.
I ran test.exe /regserver to register my COM server.It worked for several days.
I did not change any code, and now I ran test.exe /regserver, the classes could not write to Registry anymore.There is no any errors popped up when I run the command.
I found the route cause.
There was a "-" in my file path,so the words after "-" were treated as parameter,such as -regserver. After I put my exe in other directory whose path does not contain a "_", it worked.
Related
i am trying to execute netcfg.exe /U ms_pacer etc to uninstall some bindings to the network adapter. now everytime i pass the command through vbscript the command prompt throws an error saying 'netcfg.exe' is not recognized as an internal or external command, operable program or batch file.
if i put it in a batch file and double click on it it runs fine. but again if i execute that batchfile through a .run in vbscript it gives the same error. i read somewhere that it could be environment variable issue, but tried setting environment, looks good but the command keeps throwing the error again and again. tried it in powershell but no go, please someone guide.
Ok found the answer, when running a 32 bit compiled application which needs to access another native windows application there is a catch. though windows has provided a set of 32-bit set of native applications in a 64 Bit OS, but has not changed names of files, and have been relocated in another folder i.e. %windir%\SysWoW64\ , now everytime a 32 bit application tries to access c:\windows\system32 on a 64 bit, it gets redirected to %windir%\SysWoW64\, now if one wants to refer to 64 bit native application then do %windir%\Sysnative
I got this err msg while running my WindowsCE app:
...and so I copied NETCFv35.Messages.EN.wm.cab from my PC to my handheld, and tried to run/install that cab file on the handheld. I got:
So then I tried the same with NETCFv35.Messages.EN.cab. When I ran it on the handheld, it told me that it had already been installed:
...but I went ahead and "reinstalled." I'm not sure its default installation location, though, is the right place:
...so I copied it over again to the folder on the handheld where my .exe resides (NETCFv35.Messages.EN.cab had been deleted out of there after reinstalling). This time I made sure to install it into that same folder, rather than the seemingly random location it chose the first time:
Still, though, running the app shows me the same old "Which way did they go, George?" err msg about not being able to show me error messages (first screamshot above).
This makes me feel kind of Grimm, to the point where I'm thinking this is a pretty revoltin' development (no pun intended).
What do I need to do to be able to see the hidden err msgs?
UPDATE
This is what I got when I unpacked SYCCFA~1.001, renamed it System.SR.dll, and tried to add it as a reference to the project (it claims that it is not a .NET assembly...???):
I tried the same thing with NETCFv35.Messages.EN.wm.cab, with the same results (it looks like the same file - same date, same size...so why the name diff?)
The error messages are in a single file called "System.SR.dll". The CAB simply installs that and puts it into the GAC. You get an "already installed" error because it sees it in the registry, though it doesn't mean the file is actually there.
You can simply extract the DLL from the cab with a zip extractor (I use WinRAR, but whatever). For example, If I open this file:
C:\Program Files (x86)\Microsoft.NET\SDK\CompactFramework\v3.5\WindowsCE\Diagnostics\NETCFv35.Messages.EN.cab
It has a few things in it. SYCCFA~1.001 is the DLL. Pull it out, rename it to System.SR.dll and add it as a reference in your project. Studio will deploy it when you run and boom, you're cooking with butter.
I am currently working on my product installation in Windows XP 64-bit machine. I am trying to register my COM modules as part of installation. I am doing this by adding an entry in 'RunOnce' (registry) key to launch a bat file and registration is done from that bat file.
All my COM dlls are registered correctly but two of the COM servers (.exe) showing error that it failed to load one of its dependency dll. But the same dll is statically linked with another COM server and this server registered successfully !
And surprisingly running the same bat file directly(double clicking on it) doesn't generate any errors and its works fine for all assemblies!. I have checked this in couple of my test machines only of the machines showing this behavior. Unfortunately that't the customer tool machine.
Its not dependency dll not available issue. Because after registering all files by directly running the bat file, I could reproduce this again by adding a key in RunOnce manually and restarting the machine.
Additional info, I am accessing this machine remotely via logmein.
Exact error message: "This application has failed to start because XXX.dll was not found. Re-installing the application may fix this problem".
This XXX.dll is not available in the same path but its in another folder and its path is available in path variable.
bat file content is;
"C:\WINDOWS\system32\regsvr32.exe" RemoteControlHandler.dll
"C:\WINDOWS\system32\regsvr32.exe" ProcPgmHandler.dll
"C:\WINDOWS\system32\regsvr32.exe" GEM300Handler.dll
"C:\WINDOWS\system32\regsvr32.exe" ICEScreenAdapter.ocx
HIB.exe /regserver //Throws error
JobManager.exe /regserver
Cim300Adapter.exe /regserver
GemEquipmentCtrl.exe /regserver //Throws error
Hope this information is enough for experts, feel free to ask if you need any additional information.
Nixon
I'm trying to use Dsofile with a VBS script on a Windows 7 64-bit machine. I believe my issue is with registering the DLL.
I used this to register the DLL
regsvr32 D:\Desktop\dsofile.dll
and am told that
"DllRegisterServer in D:\Desktop\dsofile.dll succeeded."
leading me to believe that everything worked. When I try to run the test code that Microsoft gives
Set objFile = CreateObject("DSOFile.OleDocumentProperties")
objFile.Open("D:\Desktop\test.xls")
Wscript.Echo "Author: " & objFile.SummaryProperties.Author
it fails on the first line, stating that
"ActiveX component can't create object: 'DOSFile.OLEDocumentProperties"
which leads me to believe that the DLL did not actually register correctly.
I then tried registering the DLL, based off this solution, by doing the following
cd \Windows\SysWOW64
regsvr32 C:\dsofile.dll
It also informs me that it registered correctly, but once again the script fails on the first line.
How can I fix this, so that I can use Dsofile?
Thanks.
I have an ancient COM object in VB6 that has been working fine until recently. (Don't they all). The only code change that has been made (as verified by svn) is the inclusion of a new string literal in an array.
The VB6 IDE compiles the object fine. When I hit Run|Start... and execute the following test vb script from the command prompt, the object works fine and I see the dialog boxes I expect:
dim o
set o = CreateObject("MyDll.MyClassName")
wscript.Echo "Testing object"
wscript.Echo o.HelloWorld ' runs a test method that returns "Hello World"
wscript.Echo "Done"
However, when I stop debugging in the IDE and attempt to run the same vbscript from the same command prompt, I get the error:
(ProgID removed for security reasons, but it is the same as in the script.)
Things I've tried:
I suspected that the DLL may have been registered and unregistered by VB when I start and stop the debugger, so I also tried registering the object with regsvr32 before running the test script. This has had no effect.
I also removed all references to the DLL from the registry, and re-registered the object. Same error.
I deleted the DLL and re-built it from VB (File|Make...) and re-registered the DLL. Same error.
Machine is Win7 Ultimate x64, object built with VB6.
Any suggestions?
And, no, unfortunately, rewriting the object in C# isn't an option.
Microsoft says it's some sort of dependency issue: http://support.microsoft.com/kb/194801
Because it's working when you run the object in the IDE this leaves you with four possibilities:
The ActiveX dll itself is not on the system path.
The ActiveX dll depends on something else which is not on the system path.
After registering the dll, it is somehow marked as requiring elevated security to run
After registering the dll, something it depends on requires elevated security to run.
I would try opening a command prompt as administrator then run your vbscript file that starts the object. If that works then it means the problem is either #3 or #4. If it doesn't, then it means #1 or #2.
You can eliminate #2 and #4 if the ActiveX dll has no external dependencies.
Next, I'd look in my event log to see if any other errors were logged by windows about this.
UPDATE
Just found another possible cause. If the ActiveX dll is 32-bit, then the script has to use the 32-bit version of the script engine to run; otherwise it will give this error because the default script engine (x64 on that machine) literally can't find the dll.
I believe if you use \windows\system32\cscript.exe to run your vbscript then you'll be good.
Well it definitely sounds like the issue because of 32bit dll.. The suggestion mentioned above is correct but the path is wrong.. try using the CSCRIPT from C:\Windows\SysWOW64..
Try registering the DLL with regsvr32.exe from %Windows%\SysWOW64. It is different than the regsvr32.exe in %Windows%\System32 (on a 64-bit OS).
See this SO posting.