I find that under certain conditions my signed, inno created installer.exe takes about 10 minutes to open or view properties. When I run as administrator it is immediate, so it seems obvious that the UAC is somehow related. The size of the exe is around 13 MB.
If I copy the file via thumb drive to the target machine, there is no wait. If the same file is downloaded through a browser, there is the 10 minute wait, with explorer going into la la land doing who knows what. After the 10 minute or so wait, the file opens normally with no wait on all subsequent openings.
I am using ksign + commodo to sign the inno exe, and an internal dotnet exe within the inno setup, although I don't think that is a factor.
Windows 10 has the 10 minute wait even running as administrator.
This action is happening for most versions from win 7 on up. There seems to be some change in the exe contents that triggered it, but I haven't found the reason.
Edit 1: I previously contacted ksign, they don't seem to have any issues with my exe, it opens without lag in their environment. This isn't typical however, as many installations face this lag issue. I also tried making some sense out of process monitor monitoring explorer, but there is too much information going on with explorer to pick out the hanging process, unless I a looking in the wrong place.
Edit 2: MsMpEng.exe, which is microsoft security essentials, seems to running amok. This goes on almost endlessly.
Try steps described here: Offline Environment and Authenticode:
To work with UAC-enabled Windows, winsw ships with a digital
signature. This causes Windows to automatically verify this digital
signature when the application is launched (see more
discussions).
This adds some delay to the launch of the service, and more
importantly, it prevents winsw from running in a server that has no
internet connection. This is because a part of the signature
verification involves checking certificate revocation list.
To prevent this problem, create myapp.exe.config in the same
directory as myapp.exe (renamed winsw.exe) and put the following
in it:
<configuration>
<runtime>
<generatePublisherEvidence enabled="false"/>
</runtime>
</configuration>
See KB 936707 for more
details.
Note, this may not work, if your installer already has embedded manifest (more details). In this case you should try to modify your embedded manifest instead.
Related
I am building an installer in Inno Setup v6.2.1 with prerequisites, which include .NET, runtimes, and KB fixes (Windows 7 SP1). The goal is to do potentially several reboots depending on if the machine is missing KBs or .NET etc.
I am able to achieve what I want so far using PrepareToInstall and can change the text by returning the appropriate string. No problems... however I can't find a way of changing the.
Setup must restart your computer. After restarting your computer, run Setup again to complete the installation of xxxxx
Because I am creating a runonce entry, the installer will automatically run after reboot (which it does). The text "run Setup again" is not relevant in my situation and I want to change the text to say that the installer will continue once you restart.
I have tried to find where to change this text but with no success. I assume that PreparingMemo might be the candidate but no luck or not sure how to use it. Any help would be appreciated.
See Handling and customizing errors and messages in Inno Setup.
This particular message is defined by the PrepareToInstallNeedsRestart message.
You can change it in the [Messages] section:
[Messages]
PrepareToInstallNeedsRestart=Setup must restart your computer. After restarting your computer, the Setup will continue to complete the installation of [name].%n%nWould you like to restart now?
If you need to change the message text dynamically, assign WizardForm.PreparingLabel.Caption. E.g. from CurPageChanged(wpPreparing) event.
I have a webjob that I'm debugging locally as a console app. But once I stop the code from within VS2017 I'm unable to recompile the exe as I get the following error
Unable to copy file "obj\Debug\******.******.exe" to "bin\Debug\******.******.exe". Access to the path 'bin\Debug\******.******.exe' is denied.
When I look at the processes that are running theres nothing there that jumps out.
I've closed VS and restarted it, but thats not cleared the issue.
Other than restarting my machine is there anything else I can try?
You can use the Windows Resource Monitor tool. Once opened, navigate to the CPU tab and enter the full path of the .exe (e.g. C:\Project\bin\debug\App.exe) in the Search Handles text box in the bottom-mid right corner and search. You should see the list of processes currently locking on the particular resource (in this case, the .exe). Select all the unwanted processes, right-click and end process. Depending upon on the version of Windows you are running, the experience might differ a bit but the general idea is more or less the same.
this is my first time on such a prestidigious site, so please welcome me by assisting me. I am doing independent development and am primarily a music designer. So that is why I may not sound like a real pro coder but nevertheless truly love creating my music through automative processes.
My present issue is this:
Windows 8.1 Pro
AutoHotkey 1.0.48.5 32bit (running as Admin)
Everytime I attempt to use the command 'RUN' with an .ahk target, I get the expected result except that the .ahk residing folder is opened by MS Explorer. I suspect that something like the fact that AutoHokey is an unsigned app, windows does not want it to run flawlessly. I am now trying a number of Administrative Tool Services disabling, but with no success yet.
RUN C\:XZN\Mecanisms\AnyAHK_script.ahk
;;or
RUN AnyAHK_script.ahk, C\:XZN\Mecanisms
;;or
RUN C\:XZN\Mecanisms\BactchfileLaunchingAboveScript.bat
;;or
RUN AnyAHK_script.ahk, C\:XZN\Mecanisms
Would there be a workaround this at the OS settings level or another way to run/start an .ahk file?
I tried the 'Comspec' approach as well as running an .ahk from within a batchfile, but the .ahk always get intercepted whenever it contains a 'RUN' command requesting an .ahk target.
Thanks.
You are using outdated version of AutoHotkey which is more than 5 years old. Always use AutoHotkey and its documenatation from http://ahkscript.org/ (current uptodate version, new official website)! AutoHotkey and its documentation from autohotkey.com is outdated and you may have some problems using them!
One thing to try if you only have this problem on win 8 is to Enable interaction with administrative programs http://www.autohotkey.com/board/topic/70449-enable-interaction-with-administrative-programs/
That script modifies the executable file's embedded manifest, then creates and installs a self-signed certificate and uses it to sign the file. The executable will not run on any other system, unless you install the certificate used to sign the file.
But lets see some script code that way we have something to test with and can better help you out...
My site is hosted on Azure. I need to programmatically turn off Internet Explorer's default enhanced security configuration settings whenever I repave or redeploy a new box on Azure.
How do I do this?
I found this article on another site http://jetlounge.net/blogs/teched/archive/2009/10/25/fix-ie-esc-won-t-turn-off-internet-explorer-enhanced-security.aspx. It included the following command line syntax, but on my local box I couldn't find the IEHARDEN.INF file it referred to. I also don't think this solution is Azure-specific.
rundll32.exe setupapi.dll,InstallHinfSection IESoftenAdmin 128 %windir%\inf\IEHARDEN.INF
I need to turn off these default hardening settings under Azure because I have a 3rd party IE screen capture DLL that needs to execute Javascript on webpages.
I think that this approach, shaped in a Windows Azure StartupTask running in Elevated execution context will help you.
Just remember that the .bat or .cmd file you create needs to be UTF8 encoded. There used to be some issues with the batch files if they are not UTF8.
UPDATE
I decided to update the answer, because it would have been too long for a second comment. I want to first make clear that I do not intend to offend anyone and the next is just mine personal view and thoughts.
Well, I mine vision might be (is) distorted through mine prism. But, I think that these specifics has nothing to do with Windows Azure itself.
These are OS related configuration specifics and the approach would be one and the same (with some variations) regardless of a (hosting/cloud) provider. If you had to deploy your solution to a dedicated (or virtual) server, you would had to create some kind of scheduled task, or startup task to make these configuration changes. Or even interactively login to make these changes.
Since Windows Azure offers the StartUp Task, it is up to us (developers) to decide what to do and how to shape the OS according to our needs.
The OS configuration changes that one can possibly need are only limited by the total ammount of all available Windows Server 2008/R2 configuration options. I personally do not believe that these needs to be reflected in Windows Azure documentation by any means. They have their place in Windows Server documentation. It is arguable which are "commonly used", because what might be common for one, might also be "never needed" for others ...
I have been looking at an issue for a week straight and have been unable to figure it out and I am desperate for the fix.
On a client site, we have two environments: UAT and PROD. UAT works perfect (Please keep this in mind). We are now trying to deploy the solution to PROD but certain parts of the solution are not working.
We have developed an asp.net application that we provide to clients to allow them to invoke SSIS packages (there are a couple of drop downs that they first select then click a button named "invoke").
When the user clicks the Invoke button, a batch file named InvokeSSIS.bat is called that assembles a command line call to dtexec with the appropriate parameters.
I'm having a problem with a particular package that is responsible for calling an executable which generates a spreadsheet that i will be importing into my system.
The executable is on an mapped H:\ drive.
I have modified the InvokeSSIS.bat batch file to capture the command the batch file is generating. If I execute this command from the command line, it works perfectly. From the webapp Invoker, it executes the package but the tasks responsible for calling the executable doesn't execute as the entire package takes only 1 second to complete (whereas it should take about a minute.)
The executable DOES have a GUI, but it is NOT interactive. This is because when you call the GUI with specific parameters, it automatically runs in batch mode and executes a macro used to generate the desired spreadsheet.
I know this is ok because it works on the UAT server AND it works from the command line!
I have checked the permissions on the executable (bu right-clicking the executable and clicking properties.) I have granted Full Control on the executable to the same user specified as the identity tab of the application pool i am using.
Can someone please help me? As I said I am dying over here!
Please let me know if you have any ideas or what other info you need.
Environment (both UAT and PROD)
OS: Windows Server 2003
IIS 6
asp.net 2.0
SQL Server 2008
Thanks!
Steve
You can't use a mapped drive with IIS.
You must use the \\servername syntax to reach files on other systems.
I agree with user544284 that this is at least in part a mapping issue. I'll ignore for a minute the complete insanity of having a web application call a batch file to start an executable that's on a remote network drive through a drive letter mapping.
Most likely the UAT box has something set up that maps that drive letter for you which Prod is missing.
The only other possibility is a security violation is occurring. Running .exe's from a network drive is generally frowned on. Do the two environments have the exact same version of windows? Are they configured the same with regards to UAC? Any differences here are going to be important.
Which brings up an interesting thought. I wonder if someone logged in to the UAT server using the same account credentials the app pool is using and added the ip address of the machine where the exe lives to the list of "Local Intranet" sites... Or, if they installed SSIS on the UAT server itself.
Just because YOU can log in to the server and run it on the command line means nothing. You have to find out if the drive letter is mapped at all for the user that the web app is running under and whether that user has the required security bits and whether the local OS will allow it regardless.
Okay, I can't ignore it: hairbrained is the nicest adjective I can come up with for this "architecture". Do yourself a favor and go back to the drawing board on this one. It has the word "brittle" written all over it, as you have already found. Instead of building out a batch file to call dtexec, just do it directly either by something like this or this.