Ensure your program starts in Windows Safe Mode - windows-7

Is there a way I can ensure that my program starts even in the "Windows Safe Mode" ?

There are several ways to do so. One of the easiest way to do this is adding your app in Windows registry.
Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Here you will find a String value with default value data
Shell = explorer.exe
Now you can add your app here by editing its value data, so that after edit it will look like
Shell = explorer.exe,app1,app2
This will make these apps to run in safe mode.
Warning: Do not remove explorer.exe . Doing this will prevent auto start of Windows Explorer.

Safe mode is a mode of windows in which only the very bare minimum core windows features are started.
By design it does not load or automatically start up any 3rd party applications, services or drivers.
The purpose is to have a minimal running version of windows incase one of those 3rd party apps, services or drivers are malfunctioning and preventing windows from working correctly.

Related

How to replace or block Windows Taskbar and Desktop for security reasons, programatically?

Like some cyber coffee applications that disables the user ability to use any other application but only the ones started inside that cyber admin application panel, I searched the Internet for some way of doing it in Delphi:
Remove the Windows Task bar;
Disable the Alt+Tab function;
Disable the Task Manager;
Be able to do/undo that changes in a configuration panel.
These needs are for keeping users from downloading viruses and making changes to Windows configuration or even play games, if it is the system administrator's preference. The own program would serve as a container for authorized applications to run inside then as if it were a MDI application. That is already working
Of course that the system manager will have the options to disable that or revert.
Is there a way to make those four configurations in run-time with Delphi XE3?
I'm not familiar with Delphi. I'm also not sure if it is possible during run-time. But you could do the following:
Write to the registry to prevent alt-tab see this.
Again write to the registry to disable Task Manager see this.
Sounds like you can disable the task bar too by the registry see this.
On your control panel have options and when they hit save, save and restart the computer.
This is provided that Delphi can write to the registry (I believe C# and C++ can). If not, you could create .reg files and execute those by calling cmd.exe with arguments. This I think will cause some pop-ups though.
Update: You may be able to load in the registry changes without a signing out by killing explorer.exe and then loading it again. This may only load parts of the updated registry though.
I'd suggest booting your hardware into Linux, and then run a Windows virtual machine that is as locked down as possible using the existing kiosk mode security settings in Windows. This VM then runs your MDI application when the VM boots. When the MDI application exists the VM reverts to a snapshot of the known good Windows configuration.
You strip down a Linux OS to include only the bare minimum components needed to host your Windows VM.
I'm assuming your MDI windows will only host applications your organization has written, not arbitrary Windows executables. Otherwise you are asking to re-write Windows itself, which will prove impossible.

shutdown windows 8 from metro app

I'm doing a metro app for Windows 8. And as part of its functionality, I need to initiate shutdown of Winodws 8 from the Metro App. Here are the questions:
1) Firstly, I researched a lot on this topic and I found out that System.Diagnostics.Process is not available for Metro App. So, is there a another way around?
2) Even if I can't directly shutdown, is there a way to trigger it from the Metro App?
I would prefer a solution in C#.
Thanks.
Doing this just isn't possible in a Windows Store (aka Metro) app. Such apps are strictly limited in what they can do, nothing that affects the way the operating system works or affects other processes running on the same machine is possible.
These restrictions are enforced by omission if you program in a managed language. The .NET framework class you hope to use is just missing. If you program in a native language like C++ then you can try to work around it by using the winapi. But that doesn't work either, a Windows Store app runs in a sandbox that simply fails the api call. Very similar to the Protected Mode feature of Internet Explorer, the security model is named "App Container". And enforced by the store screening procedure, even if you did find a hole in the sandbox then you can't get it past the validator and can't get it published in the app store.
Key point here is that it just doesn't make sense to write a store app to reboot the machine. Because there is nothing such an app could do that requires a reboot.
To shut down or reboot Windows 8, just shell to the following:
Shutdown:
%windir%\System32\shutdown.exe /s /t 0
Reboot:
%windir%\System32\shutdown.exe /r /t 0

How to automatically run a VB6 compiled software as Administrator and in Compatibility mode

We have an ERP application which is built in VB6 and it was running just fine till a few of our customer upgraded all their systems to Win7.
This software is programmed in such a way that it registers a few plugins (found in plugin folder) which are COM based at runtime. Now when the software is run by user without setting Compatibility Mode and Run as Administrator setting it fails and crashes.
I know we can manually set both Compatibility Mode as well as Run a Administrator by right clicking on program executable and then going to its properties. But this looks very unprofessional.
I think there will be some way to tell Win 7 to automatically run a software in Compatibility Mode and Run as Administrator.
Please help me.
Compatibility is an administrative function, not a development or deployment function. It is better to fix the application where possible, especially to remove any requirement for elevation.
There are plenty of tools for investigating the issues so you can correct them. However globally registering "plug ins" at runtime is a nasty one. VB6 component self-registration is always global unless registry virtualization can redirect it. Why not create installers for the plug-ins that can run elevated once during installation?
There are ways to set compatibility less manually, even as part of installation - though Microsoft discourages this. Maybe take a look at:
Compatibility Fix Database Management Strategies and Deployment
However the effort required might be better spent on remediating the problem. Support costs will be less over time.
As the other answers have said, you shouldn't need to run all the time elevated.
If you want to register the plugins after its started (as a normal user), you can use ShellExecute() with the "runas" verb to run regsvr32.exe, or use COM elevation which has been discussed many times before.
You can indicate that an application must run as admin by specifying it in the Application Manifest, which in an xml file that you can either embed or deploy with your application.
Once your application is running with admin rights it should be able to register and load the plugins. You should not need to run in compatibility mode to access the COM plugins.

Why CreateProcessAsUser requires interactive window station on Vista/Windows 7?

I had to delve into this because the code that worked fine on Windows 2003/XP doesn't on Windows 7. Application launched by the use of CreateProcessAsUser fails with 0xc0000142 error code. The difference between my old code and one available from MSDN at Starting an Interactive Client Process in C++ is that I didn't set up privileges and to Window Station and desktop. I've updated my code according to the example, but I would very much like to understand which change in newer Windows made running processes in interactive Window station a requirement?
At least part of the requirements derive from the change to run interactive processes in a different session from services. This was done so that applications could not run 'shatter' style attacks against privileged services. More information is available here.

How can I permanently bypass Windows XP startup?

I have an application for Windows XP. This application is deployed with the hardware. The application is the only application that ever runs on these machines. These machines are never connected to the internet. I'm interested in instant-on (or quick-on) options that bypass the Windows XP startup for these machines.
This is similar to Windows XP "hibernation", but not exactly. With hibernation, the memory state is only read from disk once - the very next time the system is turned on. I want a memory state permanently stored to disk, so the system always starts from that same spot every time, regardless of how it was shut down. How can I achieve this?
Sounds like you're looking for the Hibernate Once, Resume Many feature of Windows Embedded.
If you like "hibernation", you may use VMWare.
Install a ArchLinux and VMWare on the host machines.
Prepare your Windows XP as the guest OS.
Customize startup process of the host, let it run VMWare and restore Windows to the snapshot.
Hmmm, the short answer is "not easily!", but one way could be to try playing around with replacing the windows shell with your own application / script that launches your own custom interface / state instead of Explorer as the default. Basically it's done using this reg key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\shell
Info on this actually seems to be reasonably scarce after doing a quick Google search, but this link below provides a little more detail:
http://www.trap17.com/index.php/how-change-windows-xp-shell_t20367.html
I think if you do a Google Groups search on "Windows XP shell replacement" you might get some more informative results.
You could try installing TweakUI on them, and having them autologin. Once you do that, just add your application to the Start Up menu (or in the registry, under:
HKLM\Software\Microsoft\Windows\CurrentVersion\Run
Jeff Atwood has a post on this very thing.

Resources