Cannot change dcom permission on Windows x64 2012 R2 datacenter. The component is 32 bits. I start the config running "mmc comexp /32". I can change it, but Windows won't save the configuration. I check "customize" (the picture shows Windows in portuguese, so it's 'Personalizar') and save. When I come back to the security tab, it's again on "Default". I already went to regedit and gave all possible permissions on the component entry. Check image here: http://imgur.com/VVNVLMo
Another thing, I can't change the configuration of most components,
they are grayed out.
Any idea to fix this? Windows makes so unthinkable problems :z
Related
I have a Win 7 64 bit PC running VS2010
I have one test machine that is generating issues for me (a Win 8 one), but I cannot connect to it via Remote Debugger.
To complicate issues, this remote machine is a VM hosted via Paralells.
I have turned off all firewalls (I don't like this, but that makes the server appear in the VS2010 window, so I know I need to come back and tweak the firewall.)
I go to the remote machine, start up vsmon (I have tried both x86 and 64 versions), and the server starts ok.
try to connect and I get "MSVSMON.exe does not appear to be running on the remote instance." (Even though I know it is as I just started it!)
I have gone into settings and enabled "Any User" and "No Authentication". Restarted VS2010 and still nothign. Exactly the same error message.
I have a User called Matt on both the Win 7 and Win 8 machines, both with admin rights to the resepctive boxes. But still the same error message.
So what steps have I missed?
(and as a supplemental, I am sure that in teh documentaiton for the remote debug server download, it states that the install will create the necessary firewall rules, so why is my firewall still blocking me seeing the Win 8 Machine?)
Im out of ideas on this one, so if I can't crack this soon I'll have to move my dev envrionment across to the win 8 vm lock stock and barrel, which then means that my test machine is no longer an exact replica of a client workstation.
Copy directory c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger\ to the remote computer.
Start x64 version of msvsmon.exe as user Matt. Do not enable "Any User" or "No Authentication". User Matt should have administrator rights.
Start your visual studio 2010 as Matt.
Try to connect to remote debugger. It worked for me every time. If it does not, consider using higher version of visual studio (i.e. vs 2013 community edition is free and should work well).
I have a VB6 app that loads initially (for a small prompt to enter a license key, only on the first time). It works fine on my machine (windows 7).
I had complaints of it crashing on someone else's machine (both xp and 7), so I made a Windows XP virtual machine. I installed it on the virtual machine, it crashed. I wanted to see where it crashed so I installed Visual Studio on the virtual machine so that I would get a debug prompt. When I ran the program again, it worked.
I am more familiar with C++ and had these kinds of problems, so I figured it was some sort of runtime issue.
I found this VB6 SP6 Redistributable Runtime:
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=24417
I installed that, and it still wouldn't run.
Any ideas where to go from here?
Edit:
I have tried depends.exe, it only shows MSJava, which I've heard I can ignore. Does depends.exe also show things like .ocx (Active X controllers?) that are required?
Also, from the cmd prompt, %errorlevel% doesn't seem to get populated. Is that a VB6 things, or does that indicate that this is truely a crash and not a user exit?
Open the Visual Basic project and check both "References" and "Components" under the "Project" menu.
Since it is crashing with the VB runtime installed it is likely a component that you have referenced in the project that either does not exist (or is not registered) on the client under test.
This should be a simple fix.
I had the same problem on my windows 7 computer.
I have uninstalled everything, changed my windows theme to Windows Classic.
I changed following properties of VB setup file.
Right click on setup.exe and go to properties and in compatibility tab change the compatibility mode to windows XP SP2. And in settings uncheck the following check boxes.
Disable Visual themes
Disable Desktop composition
Disable display scaling on high DPI settings.
Run this program as an administrator
And have completed installation.
Followed by installing VB 6 service pack 6 from here.
http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=24417
Hope it helps.
It may require something else other than just the runtime, have you tried viewing it with dependency walker http://www.dependencywalker.com/ on the machine that it crashes on?
It should quickly point out any missing references.
Maybe try again, create a new VM, but install the remote debugger instead of the full VS.
You should create an installer for your application. There may be more dependencies than just the VB6 runtime. A good installation tool will detect at least some of necessary dependencies for you. Have a look at this question or this question
I'm not able to run visual studio 2008 by choosing 'Run as a Administrator' it says 'Application Cannot start'. Any solutions please.
OS : Windows 7 64 bit
IIS 7.5
I've just come across a similar problem myself, where an external tool won't work when VS is run as admin. On my case, the tool tries to access a mapped network folder. Turns out that the mapping applies only for the non-admin login token. Does you VS happen to access a mapped network folder?
See: Programs may be unable to access some network locations after you turn on User Account Control in Windows Vista or in Windows 7. Link includes a possible solution.
BTW, the problem here is probably not VS-specific. Since it seems to regard Windows permissions, it should probably have been asked on ServerFault.
I have a 32-bit application I'm working on that targets .NET 3.5; VS2010 is my development tool. My app requires elevated privileges for a variety of things, so I have an application manifest for it that has the following line in it:
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
Because it's the right thing to do, I also have the lines in the manifest that indicate the application is compatible with Windows 7 and Windows Vista:
<!--The ID below indicates application support for Windows Vista -->
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
<!--The ID below indicates application support for Windows 7 -->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
The app runs great on Windows 7 and Windows Vista. It immediately pops up the UAC prompt, it does not get affected by registry virtualization, etc. The manifest is clearly working there.
However, on 2008 R2 none of these things are true. UAC prompt does not appear. Registry virtualization happens (my primary problem). It's like it's completely ignoring my application manifest. I have no idea where to look or what to check. I have run the exact same bits on 7, Vista, and 2008 R2 and get exactly the same results every time. My 2008 R2 install is completely vanilla, as it's just a freshly-installed VM for testing.
Also, I'm fairly sure that Server 2008 is acting just like 2008 R2, basically ignoring the manifest. Any help would be greatly appreciated!
I have figured out the strange answer to my own question, though it comes in two parts:
For some reason, I'm not getting a UAC prompt in either 2008 or 2008 R2, but in both cases the app is getting properly elevated and application virtualization is disabled correctly.
My app, being 32-bit, was writing into the Wow6432Node registry key, hence I thought virtualization was happening because my changes weren't appearing. If I had tested on 2008 x86, which I had not, I would have found that the changes were appearing there but not in the x64 OSs.
Server 2008 R2 has UAC turned off by default. If it's turned off, then users from Administrators group have full admin rights and non-admin users do not have them and can't be elevated into an administrator account.
We have a Server/Client cybercafe management application which used to work fine on Windows XP and Vista but now fails to run on Windows 7.
The Client was supposed to get 'Locked' on Client PCs of the Cybercafe, meaning it replaced Windows Explorer by changing the registry key
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell"
to the path to the Client application's EXE file.
This worked just fine on Windows XP and now on Windows 7, neither Explorer.exe nor Client.exe are run and just a blank, blue screen is shown.
We thought it might have something to do with UAC so we disabled it, with no luck.
When we managed to start Explorer.exe on the Client PC through another computer, and used the Explorer window to open Client.exe, the Client started just fine.
(Note that running Explorer.exe didn't start Windows Shell and just opened an Explorer window, since the registry key was pointing to Client.exe and Shell doesn't start unless the registry key points to Explorer.exe)
Ideas, everyone? Any big difference between XP and 7 in this area?
Fixed it. Hope someone finds this useful:
A 32bit app running on 64bit Windows can't access certain areas of Windows Registry. The request to access that section is routed to some other key. That's why our application couldn't lock on Windows 7 (It was a 64bit Windows).
Changing Client.exe from x86 to "Any CPU" in Visual Studio fixed the problem.
However, it was still necessary to disable UAC to allow the Client to work.