Run Software as Exclusive Shell Application? - windows

This has previously been asked (2001) but without a solution.
http://forums.techguy.org/windows-xp/58217-exclusive-shell-applications.html
In BPM Studio you have the option to run the software as an "Exclusive Shell Application". Immediately after logging into Windows, BPM Studio appears and nothing else Windows-related (taskbar, desktop icons etc) loads. On exiting BPM, the user is returned to the Windows login screen.
Does anyone know how this is achieved? I want to do something similar for some software i'm working on. I've done a lot of research and can't find any leads!
Thanks

The key in the registry is called:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon -> Shell
which should be set to explorer.exe. BPM Studio probably changed this key.

This sounds very much like a custom shell.
All the MSDN documentation that I could find seems to concentrate on embedded versions of Windows where replacing the shell is clearly very common. However, I believe that the principles are much the same for desktop Windows.

Related

Windows 7 - Programmatically configure a application to run in XP compatibility mode

My application needs administrative access and I want it to run without any hassles in Windows 7.
I have the following options
1.Ask the user using the application to turn off UAC. This is a last resort option and would hate to do that.
2.Embed a manifest in the application that says elevate to adminstrator privelege. This will work but it seems that it will bring up a dialog requiring users consent every time a user runs the application.
3. Configure the application to run in Windows XP compatibility mode. This works, but i had to do this using explorer->application properties. if can I do this programmatically during installation time, I would really prefer this option. My question is if there is any way to achieve this.
regards
Ganesh
Try making an application compatibility shim that says your app needs the XP compatibility mode, and distributing it with your app. A shim is a means for administrators to simplify installation of a 3rd party app that needs compatibility settings - it saves them tweaking each PC individually. You can probably roll it into your install program with a little ingenuity.
I've gotten pretty used to dealing with the UAC dialog, running Vista for the last 2 years. If it bugs you, I have to wonder how much experience you have using post-XP OS'es.
As a user I think there are two ways to look at it:
The program inherently requires admin. For these, I very much appreciate the dialog, as I know it means nobody's going to sneakily run that thing in the background on me and modify my system.
The program inherently does not require admin. Most programs only need admin to auto-update themselves (and probably shouldn't need it then). My attitude is that these programs are poorly-designed. Such a program should only invoke AUC if it discovers it needs to update, not every single frigging time I start it up. This is a security issue too, as any buffer overflow someone finds in the entire program puts me at risk.
Localize the need for UAC as much as you possibly can. The best would be to put in a separate executable. (eg: an "updater")

How to configure Visual Studio not to give UAC prompt on each run?

I have switched to Vista recently and I wanted to keep UAC turned on, as I agree it increases computer security a lot. Some developer tools I use regularly require running elevated:
PIX for Windows
Visual Studio 2005 (elevated privileges seem to be needed for debugging and for IncrediBuild to work)
mapped and substed drives: The elevated process does not seem to see the drives I have mapped in my user account. This article describes the problem, but I am not sure how could I implement its final suggestion to "map these drives in the context of the elevated login".
I have experimented with many suggestions I have found, Compatibility Administrator seemed quite promising, but the result was still not what I wanted. When I used RunAsInvoker, there was no UAC prompt, but the Visual Studio did not work. When I used RunAsAdmin or RunAsHighest, it worked, but there was the prompt.
Is there any way how to teach UAC to remember some particular application should always run elevated and never prompt me about this, or some other way how to allow me launching VS elevated without the prompt? If there is no way to do it, does there exist some security reason why it cannot be done?
Try:
Administrative Tools -> Local Security Policy -> Local Policies -> Security Options -> User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode = Elevate without prompting.
I've had to turn UAC off for my 2008 dev system also, despite similar feelings about wanting to be able to use it. It's just too painful to need to keep track of the running context of every single application in order for things like drag/drop between windows to work, or interacting with remote systems, or debugging scenarios, or any number of other tasks. UAC was a good idea in theory, but there seems to have been so little effort put in to making it functionally useful for real-world power users, that at the end of the day, the only feasible solution is to disable it entirely.
Windows 7 will purportedly be somewhat better with eliminating the constant prompts, but unless they really work to address all the cross-application and remote access issues, it's still going to be a non-starter for anyone other than novice users. Here's to hoping they eventually get it to be actually usable.
VS 2005 was a pain in Vista, and there's a lot of little gotchas even when running as administrator. See if you can upgrade to 2008, which works a lot better on Vista.
Unfortunately UAC prompt is mandatory in windows Vista, when UAC is enabled.
One solution that worked for me is to have a elevated command line and a bunch of non-ui shell scripts that run elevated from there for some tasks.
Also to debug I've setup another computer in which I can run a remote debugging session, it is a bit tricky to configure with VS 2005, the plus is that if you crash/hang the remote session it didn't crash your main computer :)
PD: VS 2008 is slightly nicer in vista than VS 2005 give it a try if you can.
As far as I'm aware, you can't get everything you want (UAC on, VS working without prompts).
However, there's a better workaround than "have someone else test it with LUA:" A Virtual PC. Use Virtual PC (free from Microsoft) to create a guest operating system. Install Vista and set up a regular user as well as your default admin. Test your apps on that VPC using the regular (non-elevated) user. This at least gives you the early indication of LUA issues without too many major headaches.
I agree that it's a bit of a pain (and I've noticed VS2008 doesn't bug me with UAC prompts under Vista nor Win7 beta), but it is what it is. VS2005, particularly in debugging, requires elevation to attach to processes, etc.
For the record, my current "solution" to this problem, after a few days of experimenting with it, is:
turn UAC off
make sure somebody else tests the application with a Standard User Acount on a regular basis
... i.e. use the same pattern which worked in WindowsXP before.
I would like to see some other solution, but so far nothing I have tried gave me all of what I want, i,e. UAC on, Visual Studio working and no prompt on running VS. I would like to keep UAC on, but it was too annoying for me to confirm the elevation every time I run the tools.
Norton has an interesting tool to de-tune UAC and make it a little easier to live with...at the cost of feedback about what programs you run going to Norton. There is a good write-up about it here:
http://www.betanews.com/article/New_Norton_Vista_tool_trades_UAC_for_online_feedback/1223668881
The download is here:
http://www.nortonlabs.com/inthelab/uac.php
Finally, there is an interesting little tool to "snooze" UAC which costs $5 (30 Day trial). I can't vouch for either tool as I have not tried them personally.
http://www.uacsnooze.com/

When developing, do you turn off UAC in Vista?

I didn't upgrade to Vista until May or so and one of the things I've always heard developers I know in real life say is "first thing you should do is turn off that UAC crap"
Well, I've left it on this whole time for a few reasons. First, just as a failsafe in case I do something idiotic like have a momentary lapse of reason and run an attachment from an email, or in case I view a site which hits some unpatched exploit. Second, as a big of an experiment to see how good or bad it really is.
Finally, I figure that it enforces some better practices. I used to develop every website in Windows directly in inetpub\wwwroot (Visual Studio .NET 2003 more or less required this) but now I develop them elsewhere because the UAC clickfest is a nightmare. I figure this is Microsoft's way of saying "you should really be doing it this way".
By way of another analogy - if you wrote a web app which runs on XP and 2000 just fine but requires 50 different security features of Server 2003 to be turned off, the real solution might be instead to just fix the application such that it doesn't require the security features to be turned off.
But now I'm having to work with an app which is really really NOT designed to be developed outside of inetpub/wwwroot and so UAC is really a nuisance. It's beyond the scope of the project to rectify this. I want to stick to my guns and leave UAC on but I'm also worried about being so autopilot about clicking "Yes" or "Allow" three times every time I need to modify a file.
Am I just being hard headed? Do most developers on Vista leave the UAC on or off? And for the instance described above, is there a better/easier way?
I think it is necessary to leave UAC on on a test machine, so you can see what a real user would see using your app. However, I turn it off on my development machine since I find it distracting, and I trust myself enough to not need it.
(Hopefully your test machine != your dev machine right?)
All this being said, I support UAC, and I am not recommending anyone else turn it off, especially 'common users'.
I code in a standard user account, with UAC turned on.
No I do not close UAC.
Programming C# winform, and web with IIS. Database is progresql. No need to bother with UAC. Some program only require 1 authorization, not a big deal.
I keep UAC on. I find it useful to develop in an environment similar to my end user. That way if I write any code which is trying to read / write from restricted areas I will know about it quicker.
UAC is incredibly annoying at first when you get a new system. The problem is that when you first start out with a new install you have all kinds of programs to set up and settings to tweak. It seems like you see the UAC prompt every 5 minutes.
After a while, two things happen:
You're not setting up as much new stuff.
You've become a little more used to the prompt.
At this point UAC isn't so bad anymore. I have UAC on and I've only seen one or two prompts in the last couple weeks. That's right about perfect: if I see a prompt I wasn't expecting I know to make sure I really want to proceed.
I will argue that the 2nd effect kind of defeats the purpose. What they should do is have UAC disabled by default, but for the first month only. After the first month prompt you to turn UAC on, where the default option for someone who doesn't really read things is to turn it on. Then people aren't annoyed during their setup period, and it's easier to make an informed choice about what you want to do with UAC.
I leave it on
I leave it on, but have it set to automatically elevate privileges when necessary. It's a fine distinction, but a distinction nonetheless.
Services like Microsoft SQL Server runs with administrator privileges. Visual Studio on the other hand does not. Nor do most developer-tools.
I make heavy use of virtual machines to 1) make sure my development environment is safe at all times, and 2) to test out software with the potential of leaving my machine FUBAR. And 3) to limit down-time, restoring my development environment, "in case I do something idiotic like have a momentary lapse of reason and run an attachment from an email" :)
I have been using Windows 2008 in my workstation following the advices on http://www.win2008workstation.com/wordpress/ and it has worked great for me. I don't remember turning off UAC, but certainly I haven't suffered it, so I guess it's turned off.
As others have said, you do need to have test [virtual] machines that are configured as close as possible to the ones your users will have so you won't have any surprises deploying your app.
I think whether you do this or not should depend on the target audience for your application, although I can completely understand people disabling it.
If all your users run Vista with UAC disabled then I think you can get away with turning it off, but this probably isn't realistic--or advisable. At the other end of the spectrum, our applications are used by a vast number of people with every conceivable version and configuration of Windows from Win2k onwards, and obviously including Vista and Server 2008. Since we're an ISV with no control over our users' environments, or over policies governing their privileges and administration, I always leave UAC enabled--even though it annoys me beyond all reason at times--because then I know about any possible problems it might cause for people using our applications sooner rather than later.
Disclaimer: most of my actual coding time is spent on Windows XP, although I have a Vista 64-bit test machine under my desk which I use on a daily basis for testing. Generally I'll use this box around 20 - 30% of the time.
Developing or not developing - was the first thing I did after installing vista. Just seemed an annoying nuisance at best.
Instead of running antivirus to suck away my CPU cycles (I need as many as I can with RDPs and VMs running all the time). I just leave UAC on as a safeguard to double check and make sure only certain things run. It does more than that though, it also restricts programs access to sensitive areas, so a program basically can't trash your system without you allowing it through UAC. I have not had a problem yet and my system runs only what I need it to run, quickly and smoothly.
It's too annoying for me, it gets turned off as soon as I install Vista.
I turn it off as soon as I install the OS. Security by endless modal dialogs is no security at all. Normal users just get used to clicking even more 'OK' buttons after a couple of weeks or so.
EDIT: Wow, down-voted huh? Must be some Microsoft employees around here...Of course it should remain on on a test machine, probably should have mentioned that.
I turn it off on computers that I am using.
When testing, I test in the target environment, which means I may have UAC on or off.
I see no benefit to developing with it on.
I find it extremely annoying and turn it off at all times, I trust myself enough to not have to have fail safes in place. If I screw up and run some dodgy application that's my bad and I'll live with the consequences. Meanwhile I'm not spending 5 minutes of my day clicking though some damn annoying popups.
I have it off, but that's because I trust myself entirely too much. Its funny though, it seems to make the average user (I live in Jourdanton TX, we have a lot of "average users" here in the middle of nowhere) afraid of the control panel, because it causes all these weird prompts to come up and wants their password every 5 minutes if they start to poke around.
That said, I think it depends on your level of expertise with the system. On your dev machine, yes, definitely turn the darn thing off. I haven't gone a day this week without needing to install or update some piece of software, and I don't like having to elevate myself to admin status to have to do that.
What I would really like is the ability to have it elevate for a period of time, or say automatically turn itself back on when I log off, so that I could do an entire session's worth of installing stuff without being bothered, and then be secure again when I was done and (inevitably) had to restart the machine as seems to be common practice with windows installers now.
And all that ranting aside, I think for your test machine, it should definitely be on. Not because I necessarily agree with the feature (any more than I agree that the Administrator account should be disabled permananty, I love that account way too much) but because the User is very likely to have it turned on, and you need to see your program through their eyes. This is especially true if your program is going to require elevation, say to change a setting or modify a certain directory, so that you can prompt your users to accept the UAC warning in your program, which adds an extra layer of comfort to the user I think.
Oh, and as for the one program, let me harp on you just slightly. Shouldn't the program have a define somewhere in the main header files that tells it where its "working directory" is? If this is already the case, then why is it so hard to change that working directory to somewhere else? If its not the case, shame on you, and you should go fix that. ^_^ That would have saved you a lot of trouble.
-Nicholas
I'm running into issues where our build scripts do things like manipulate registry entries or add things to the GAC. We're trying to get away from this stuff but until we do it's there and requires privilege escalation. So the build scripts get run from an Administrator command window. The problem comes in when I open Visual Studio 2008 and try to build part of the application - I can't as a normal user because the output files can't be overwritten because the build in the Admin console produced the same files at a higher privilege level. It's causing me a lot of frustration and I'm thinking the best way is to turn UAC off for now but I'm very reluctant to do so.
Because I've got post-build scripts to copy executables into the Program Files directory for testing I run Visual Studio with elevated privileges.
One tip I've found that makes life easier, is that to quickly start a command prompt with elevated privileges you can:
press Window Key
type "cmd"
Press Ctrl+Shift+Enter
Left cursor key (with right pinky) to move to "Continue" button on UAC dialog
Enter
I always keep one open for launching my IDE and running build scripts.
The only downside I've found is that elevated windows don't interact with some of my window tweaking software like KatMouse and Switcher.
No, but I do change some settings:
Do not prompt for elevation if not in the administrators group.
Evelvate automatically if you are the [machine]\administrator
I do not put myself in the administrators group.
Juts a plain old user, with no elevation prompts.
Use Run As if developing/debugging web apps with development server
I code with UAC off. I found annoying to see all those popups when i open visual studio or star uml, or just want to change a setting in my machine. I have always installed a good internet security suite that keeped me "virus free" on my machine for long years and i don't see the point to have always an "are you sure" prompt on every task i do. I agree with Ed because everyone click ok.
Exemple : install a firewall to some member of your family. When they will be prompted if app XYZ can connect to the internet, they will click yes. They will not make the distinction between a good app and a spyware/virus. It's the same thing with UAC.
I leave UAC on, but have VS set to always run as admin. The only real reason why I do that though is that I mostly work on software that requires admin permissions to run anyway. (And yes, I know that should be the minority, but my app happens to be one of those -- it's a soft-realtime hardware controller.)
For general purpose apps, you must at least test with UAC enabled; while you could do that on a separate machine, it's easier to test on your dev machine. And the prompt isn't that much of an imposition, especially if you disable the "secure desktop" option (which reacts very slowly with most graphics cards when enabled).
If you stay on Vista, turn off UAC and rely on Microsoft Security Essentials' real-time monitor to intercept anything that wants to alter your system. Or, upgrade to Win7, where you can leave UAC on and control the levels at which you want UAC to notify and interrupt the execution.
EDIT: It's very easy to exploit a Windows computer anyway, so what's the sense in having UAC turned on, if it really doesn't guarantee protection?

Error accessing Project > References window?

In Visual Basic 6, when I attempt to access Project > References, it throws an error:
Error accessing system registry
I am:
Logged in as the local computer administrator
running Windows XP Professional and
I can execute regedt32.exe and access all the registry keys just fine.
VB6 was installed as the local administrator.
Any idea why this happens?
I'm running crystal reports 8.5 and it supposed to already have fixed that issue but apparently I still have the issue with 8.5 installed. I have also made the attempt of reinstalling crystal reports with no luck on the issue.
Depending on the Windows OS you have (I have Windows 7 Enterprise), you might want to try giving administrator rights to the REGTLIB.EXE (located in C:\Windws). Right click on the REGTLIB.EXE file. Select Properties from the pop-up menu. Then select the Compatiblity tab. On the Compatiblity tab, check/select the Run this program as Administrator checkbox. Click OK to save your changes. It might take take care of the problem for you. It worked for me. Good luck.
For me this worked:
goto C:\Program Files\Microsoft Visual Studio\VB98
change the property of VB6.EXE by right click->Compatibility In privilege level section, check the option Run this program as Administrator
If you're running Office 2010 (Beta) Word (apparently) writes a restricted registry key. VB throws the error when scanning the registry. The key I have is:
HKCR\TypeLib\{00020905-0000-0000-C000-000000000046}\8.5
For Regmon - Filter for Process Name -> "vb6.exe" and Result -> ACCESS DENIED. Helps find it very quickly.
Fixed it with PSToosl (PSEXEC) to run registry editor. The command line is,
psexec -i -d -s c:\windows\regedit.exe
psexec needs to be run with elevated-permissions.
Edit by Jim: I'm on a Windows 7 (x64) box. Elevated permissions require the PSTools solution. XP can get away with a little less.
You could try Process Monitor to see which registry keys are accessed.
I got this on a machine that I was using for VB6 development. I had been building a lot of COM DLLs from VB6 (without binary compatibility) and the cruft that had built up in the registry eventually got too much.
Have a look at what size the registry is and what limit you have set. I doubled the registry size and then went looking for a good registry hoover.
Here is a solution from Microsoft. It references the Crystal Reports problem, but the solution just uses regedit32 to walk the HKEY_CLASSES_ROOT\TypeLib and HKEY_CLASSES_ROOT\CLSID registry branches for dimmed keys and correcting the security on those keys. There are also instructions to fix the security if regedit32 is unable to access the key. Article ID: 269383
In Windows 7 go to start menu then right click "Microsoft Visual Basic 6" then select properties and click Compatibility from the dialog box that appears then tick "Run this program as an administrator".
Have you tried this? Basically, it seems that it is a crystal reports issue. Hope that helps.
Perhaps worth a try going to the "User Account Control Settings".
Regards,
When I installed VB6 on Win7-64 (using instructions easily found by a search engine), it worked fine. UAC was off -- i.e. set to "never notify."
After a few weeks I turned UAC on -- i.e. set it to its default. VB6 then couldn't compile because of the "Error accessing the system registry" problem. Unfortunately, turning it off again didn't help. Apparently the damage done by turning it on was irreversible. I can't explain why this should be, but that's my experience.
Giving REGTLIB.EXE administrative privileges while leaving UAC off sounded like a great idea, but that didn't work for me either.
Finally, using Process Monitor and PsTools as described in other posts here worked. However, I had to give Full Control to large parts of my registry to Everyone. This didn't apply just to isolated keys. It seems that the compiler needs to add keys to major nodes, so I had to open up these entire nodes.
Aside from the fact that working through these steps took hours, I'm now much more exposed than I was before I tried to increase security via UAC, However, I need VB6 and don't see another solution short of a new computer.
Lesson: Don't use UAC with VB6. Except if you've arrived here it's too late for that.
It's VB6 installation issue. Try to re-intall VB6 on your system. Otherwise open "visual studio 6.0" with "Run as Administrator". Then open/browse your project .vbp file via - New Project -> Existing tab.
I have fixed the problem. But none of the suggestion above worked. What I did is giving everyone full control over the SYSTEM key in the registry. This creats a security break. I am running 64bit Windows 7 with vb6 serice pack 6B.
I'm running Windows 10 Pro (10.0.16299 Build 16299) 64 bit. I was having this error when trying to compile a VB6 DLL.
I saw several answers in this post about running in compatibility mode as administrator. I thought I would first try just running in compatibility mode for Windows XP (sp2). I was able to compile my DLL after checking that box. I didn't need to run as administrator.

Vista Console App?

I'm doing a fair bit of work in Ruby recently, and using
ruby script/console
Is absolutely critical. However, I'm really disappointed with the default Windows console in Vista, especially in that there's a really annoying bug where moving the cursor back when at the bottom of the screen irregularly causes it to jump back. Anyone have a decent console app they use in Windows?
I use Console2.
I like the tabbed interface and that copy works properly if text breaks at the end of a line.
Are you resizing the console window? I've found that the ruby scripts (irb, etc) that use the readline library don't work correctly with resized console windows (in XP or Vista).
Effectively I believe that the readline library expects the console window to be 80 characters wide, anything else and it goes bezerk. So far I haven't found a way to fix it on windows without giving up other nice features.
I have had some pleasant experiences with rxvt (comes with cygwin, does not need an x server running). Putty is also often mentioned as a good alternative.
You could also try to get xterm working :)
Powershell
Windows PowerShell is Microsoft's task automation framework, consisting of a command-line shell and associated scripting language built on top of, and integrated with the .NET Framework. PowerShell provides full access to COM and WMI, enabling administrators to perform administrative tasks on both local and remote Windows systems.

Resources