How to know is driver signature enforcement enabled or disabled in Windows Vista, 7?
It can be disabled using a special software or using F8 on a system startup.
It's very interesting.
The mode where signature enforcement is off is called Test Mode. Many tools for disabling enforcement rely on switching into this mode somehow. The current state is displayed by bcdedit.exe when run from an elevated command prompt (right click on cmd.exe -> run as admin). It displays multiple settings one of them being "testsigning" with a value of "No" or "Yes". So the cheap way of detecting it from Delphi would be to run the bcdedit.exe, parse the output and look for this "testsigning" value.
Related
I have a very basic understanding of the Windows security system and have two problems. Can anyone point me in the right direction on how to solve this.
A) I have a Delphi XE2 application that uses a GPS clock to synchronize the system clock. The application runs under Windows 7. When trying to adjust the system clock by executing the windows function “SetDateTime…” I get a “Client doesn’t have the necessary privilege”. I’m running the application under my own account that has administrator privilege.
I then goto Controlpanel/Local Security Policy/Local Policies/User right Assignment” and change the policy “Change the System Time” to include my login account. Reboot the PC but still get the same problem with “SetDateTime” privilege.
Now if I start the Delphi application with “Run as Administrator” the application runs without problems. I don’t understand this. I thought by changing the user rights assignment I should be able to execute the “SetDateTime” function without resorting to “run as administrator”.
B) When running as administrator as described above the application works as expected except one annoying problem. Every time the “SetDateTime” function is executed (the system clock is synchronized to the GPS clock) the application screen flickers (twinkles).
I suppose that is some sort of OS warning but I don’t like it and how can I eliminate this?
Is it possible to change what key launches the BIOS menu during boot?
I am trying to use a netbooter to install a specific OS on my laptop. In order to access the netbooter, I have to press F12 at a specific time during boot. However, on the laptop I am currently using, F12 is the key that opens the BIOS. Whenever I try to access the netbooter, the BIOS gets opened instead.
Ideally, I want my device to open the BIOS when F2 or Del is pressed, and leave F12 open for netbooting. Is this possible? Can I change which key launches the BIOS?
Thanks
Unless your BIOS supports it natively I don't think there is an easy way to do it. The open source BIOS Libreboot might be able to do it, but it will be a project.
Some BIOSes have an option to change the keys for setup or the boot menu. Look in the BIOS setup. If the option is there, you can. If the option isn't there, you can't.
I have and application that is running as a windows service on Server 2008. When I run it as an application and send a print job, the print job gets processed sucessfully. However, if I send the print job to the windows service instead, it throws "The Handle is invalid" exception.
Here is the error:
Printing Thread error: The handle is invalid. StackTrace: at System.Drawing.Printing.StandardPrintController.OnStartPrint(PrintDocument document, PrintEventArgs e) at System.Drawing.Printing.PrintController.Print(PrintDocument document) at System.Drawing.Printing.PrintDocument.Print() at GrapeCity.ActiveReports.Viewer.Win.Printing.PrintImpl.DocumentPrinter.<Print>b__1e()
The service is running under an administrator account which has admin permissions.
Any help would be appreciated!
A coule things to check:
Make sure that the user account that the service is running under has the proper printer installed under his account and that it is set as the default printer.
Make sure you're using the Print method in ActiveReports that explicitly does not show any UI.
Try checking the "Allow service to interact with desktop" checkbox on the service's property page from the Services control panel applet. Although you may not be showing any UI, the printer driver may need that capability.
Finally, just keep in mind that in general printing from a Windows Service is kind of flaky. Even Microsoft's documentation for System.Drawing.Printing has the following disclaimer:
Classes within the System.Drawing.Printing namespace are not supported for use within a Windows service or ASP.NET application or service. Attempting to use these classes from within one of these application types may produce unexpected problems, such as diminished service performance and run-time exceptions.
That doesn't mean it won't work, but that it is error-prone enough that Microsoft doesn't want to help us printing in this case. I suspect this is because the printer drivers from the manufacturers are not necessarily designed for printing from non-UI processes like windows services.
Roussul
It could be a permission or printer access problem. To check whether it is related to ActiveReports or not, can you create a separate app, implement system.printing.drawing and run it as a service, just as you have it with ActiveReports and let us know.
I had this issue in a ASP.NET application. The root cause was that "Enable 32-bit applications" had been set in the IIS application pool that the website was running in.
It appears the print function tried to connect to a 32 bit driver rather than the 64 bit drivers that were installed.
Maybe in a .NET Windows app the "Target CPU" setting could also cause a similar issue? ie if you target x86 and try and run your app on x64 it will only connect to 32bit printer drivers?
I'm using D2010 under Windows 7 to write an app that seems to require admin rights (I think because it uses COM to communicate with a third party .exe, which also requires admin rights).
I've added the manifest resource as required, but when I try to debug the app from the IDE, it reports
"Unable to create process. The
requested operation requires
elevation"
...and it won't run. If I run Delphi as administrator, then my app runs correctly, but this feels like a dangerous brute force approach, especially as most of the apps I develop don't need admin privileges.
Is there any way of getting Delphi to prompt for elevation just when I run my app, rather than having the whole IDE run elevated?
UAC also catches any application that has the words "setup", "update" or "install" in their name or in many of the Version Resource fields. (Company name, App Name, Description etc.
It considers any such application to be a potential "installer" application and therefore must be run with Admin privileges.
Sounds crazy, but it's true. See the "Installer Detection" section in this document.
You can get around this by including a manifest that says that it doesn't need admin privileges.
There is none, it also doesn't work for VS:
https://stackoverflow.com/questions/3265787/how-do-i-debug-an-process-as-elevated-with-visual-studio-2008-sp1-on-windows-7
I guess you could run the remote debugger elevated and attach the IDE using remote debugging though.
It doesn't work, because the process is running as another user (or using another user token).
The IDE is trying to run the debugging process using CreateProcess and that fails when the application requires elavation, more details can be found in this article:
http://www.codeproject.com/KB/vista-security/UAC__The_Definitive_Guide.aspx
RAD Studio could run the application using ShellExecute with the "runas" verb, but this still doesn't solve the "debugging process under other user context" issue.
In other words: An elevated process can only be debugged by an elavated debugger.
Edit:
The Delphi XE2 IDE is 32-Bit and can debug 64-Bit applications only through the remote debugger (which is cleverly hidden from the user).
I guess Embarcadero could make it possible to debug elevated applications in a similar fashion.
The only way I know to debug such an app is to run the IDE as administrator. I wouldn't recommend doing this routinely, just for debugging sessions.
Actually it may be possible to debug a process with "higher level access" from a process with "normal level access".
At least until Windows XP it is sufficient to add your user account to the Debugger Users group to debug processes running e.g. with Administrator privileges.
That doesn't solve Delphi 2010s problem to run the process at all, but may be useful if you try to attach the debugger to a already running process.
I don't think this works on UAC enabled Vista+, but I thought I'd mention it anyway. :)
To be exact the UAC split token concept disables the SeDebugPrivilege:
http://blogs.msdn.com/b/greggm/archive/2006/03/30/565303.aspx
http://blogs.msdn.com/b/mithuns/archive/2006/04/04/568291.aspx
Run Delphi (any version) as Administrator.
You can change Delphi shortcut properties also (to run it always as administrator).
We have a Delphi program whose task is like a service program. It watches a particular folder for a certain period, and it works great on Windows XP and 2003, but on Windows 2008r2 64bit, when it wants to create an automatic folder, it will show this message:
The ... folder does not exist. The file may have been moved or deleted.
This message causes the program to halt, which is not good; it should not be interrupted.
What can I do about this?
P.S.: I really don't have any idea whether to post my problem in Stack Overflow or Server Fault, so I've guessed it should be here.
It's likely the VirtualStore, if you're trying to store beneath Program Files (either one). See my writeup:
http://www.clipboardextender.com/off-topic/vista-program-files-hide-and-seek
You've left out the ... folder name. While that's understandable, it wouldn't happen to have anything to do with program files (which on x64 will be split in 2 directories) would it?
Windows Server 2008 is able to use 'virtual' file pathes. That means: 'what you see is not what you get'. The Windows Explorer just shows you the 'display' name. Check the file path with cmd.exe, if the path you are trying to use does realy exist.
The reason is of cause the File Virtualization (see for example http://msdn.microsoft.com/en-us/library/bb756960.aspx and http://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx).
Because we on stackoverflow.com and not on serverfault.com I want add to all other answers that you can use Wow64DisableWow64FsRedirection, Wow64RevertWow64FsRedirection and Wow64EnableWow64FsRedirection functions (see http://msdn.microsoft.com/en-us/library/aa365743.aspx) to control the File Virtualization in your program. An example of the usage of this functions in C# you can find here http://www.pinvoke.net/default.aspx/kernel32.wow64disablewow64fsredirection.
You'll need to tell us the exact path and how do you go about constructing it. It can be as simple as the app not using env variable expansion but assuming that user's folders are where they were before.
Path virtualization (there are 2 kids actually) that people mentioned will hit you only if your app is trying to mess with system folders.
More puzzling problem will hit you if you are not expanding env vars like APPDATA, LOCALAPPDATA etc. and not expecting that there's more of them on Win7 and 2k8. Not only that default paths of user's files changed but some of them can also be on network shares - for the same user. So if you were running based on expectation that all user's stuff will be at definite paths under say %USERPROFILE% you can get hit by several surprises. Also notice %ProgramData% .
Fastest way to find out - open cmd.exe, run set and if you see some paths that you are constructing in alternative ways, take notice that you need to start expanding env vars for them. Then open cmd.exe as a 32-bit app and check set again. You can also pick them up via Process Explorer from some running 32-bit or 64-bit app.
Switching your app to 64-bit build will resolve most of virtualization issues but not the env var expansion. Also if your app is touching system folders you need to request elevated run from the code or even better make the manifest and declare it there. Then OS will yell at user up front if his UAC is on and your app will avoid that 2nd virtualization. BTW, virtualization is controllable via group policies so it might be present on some boxes and missing on others.