We are trying to automate a build of one of our products which includes a step where it packages some things with WISE. At one point WISE pops up a window with a progress bar on it to show how it is doing. If one is connected to the machine with remote desktop the build works fine but if one is not connected the build stalls until you reconnect at which point the window opens and the build progresses. Does anybody know of a work around for this? Some way of tricking windows into believing that there is a desktop session connected?
Sorry for yet another guess - but I had a problem with a wise installer locking up. It was because WISE had installed a "font" and so broadcast a "system config changed" message. My DELL had a Dell utility running on it that had a message queue it wasn't reading from so the broadcast locked up the installer. WISE made a new version for me that did an async broadcast instead to fix the problem. It's possible that there's an app on your system that doesn't bother reading its msg queue when there is no desktop.
Finally the answer: check you have the latest patches for your WISE installer. In particular, look for patches that fix lock-ups related to the windowing system.
What version are you using? Looking at the feature set, it looks like their "std" version might be limited. Perhaps unattended installs require the Pro version?
That's just a guess....
Regardless, I wonder whether you could simply code up an auto-run task for the box that calls
CreateDesktop to pretend there's an interactive login?
I found a CreateDesktop example
that's about desktop switching, and an example about unattended installs -- you might be able to use one of them as a starting point to "fake out" WISE :)
It might be worth a try...
Related
I got a weird problem with my VB app that has got me very confused. I am updating an existing program. I had to add some processing queue capabilities. On my system, unit testing worked great but when I compile it and run it on a different computer (a network server machine) it first tries to open an office install. If I cancel this, the program seems to run fine. The problem is that this program will be run in the background and I can't be hitting cancel each time it runs.
So my question is this: what is going on here? I'm usually a java developer we eclipse so I'm used to being able to include all the needed libs into the jar files automatically. It doesn't seem like the case with VB6. it seems like it expects all the same libs to be on all the systems. Is there any way to tell what might be triggering this?
The only thing I can think of that is causing it is that I'm using the "OpenProcess" function in the kernal32 lib. that the only major change I have made.
any help would be very appricated. thanks!
EDIT:
It seems that multiple versions of word were installed on the system and it was screwing things up somehow. We uninstalled one and it fixed it.
I ran into this a while ago and it was related to my installer for the VB6 app overwriting some system files for Office that it shouldn't have. Any time one of the System dlls was accessed Windows would determine that something was wrong and the Office installer would start up.
The short-term fix was to let the Office Installer repair the broken chain of dlls.
The long-term fix was to never overwrite built-in Windows System dlls.
You could also check out the Microsoft Fix it Center.
I am trying to use the HP Fortify Static Code Analyzer to analyze security concerns in a large C application and I have run into various bugs in the software itself that I cannot seem to find any answers to anywhere on the Internet. I am using version 3.4 of the software and running it on a Linux x64 system.
The main bug that I am encountering that makes it very difficult to use this product at all is that in various different places in their Audit Workbench GUI the program will just close for no reason. An example is whenever a pop-up window shows asking you a question and your answer to the question is just to close the pop-up window by either clicking on the close button or the cancel button, the whole program ends instead of returning you back to where you were when you originally got the pop-up. Another example is when I try to open the Rules Editor, either for a new Rule Pack or an existing Rule Pack, the program opens up a progress window with a moving progress bar that sits there and moves for a while but when it is finished, instead of opening up the Rules Editor, the whole program just ends suddenly.
Has anyone out there seen behavior like this? If so, please let me know what I can do about it. Thank you.
I would highly recommend upgrading to the latest (4.10 at the time of this post) version. One thing you can do to help diagnose issues is to look at the log files. These are located in (by default) [user.home]/fortify/AWB-3.40/log.
Also, since you are using Linux 64bit, you will want to ensure that AWB isn't trying to access the 32bit JRE at any time. This can be accomplished by removing [fortify install root]/jre and renaming [fortify install root]/jre64 to [fortify install root]/jre. Some of the tools default to /jre and so you can run into issues on Linux 64bit.
Before I start, another post for something similar to this request for help is located at Running a process at the Windows 7 Welcome Screen, but the responses were not quite what I believe I am looking for, and the post is over a year old so I thought it best to start a new thread for my needs.
In Windows 7 Ultimate, I am trying to create a script or task scheduler event that will run a Windows "rundll32.exe" process with arguments at the logon, lock, and switch user screens (basically any screen that is waiting for user to log into the machine).
I have tried using the startup script controls in group policy editor as well as creating a task scheduler event, but so far I am unable to get the process to display on the logon screens.
The command line I am using does work while logged into any account at any user level via the "Run.." dialog as well as via CMD prompt, and is only creating a popup that already exists in the Windows OEM Environment.
The hardest part is this: My friend just bought a new laptop. The new laptop came with this specific feature already enabled, but I have no idea what is making it happen and do not have access to the computer to check out gpedit.msc and task scheduler for possible solutions.
There are two reasons why I need this info: 1) I want the feature to work on my own laptop, and 2) my friend would like help disabling it on his as he doesn't like it.
I have been all over Google, posted at Microsoft Answers, and also posted on the laptop manufacturer's user forums. I have found very few pages that refer to the same question as I have, but none have answers that work, and since I have seen and know that this is possible, I am compelled to continue looking.
The laptop that this is currently working on was purchased with a fresh install of Win 7 Ultimate and no manufacturer bloatware/additional software added, so we know that the feature was made to happen by whomever it was that installed the OS and configured it for sale. Therefore I am certain it is just a matter of the right task or script in Windows itself before I see the results I need and then know how to direct my friend to disable his via phone.
The specific call is "rundll32.exe van.dll,RunVAN". In task scheduler I have set this to run as "SYSTEM" and set the triggers for startup, workstation lock, and local disconnect. I have tried using full path to rundll32.exe as well as the bare command. In gpedit startup scripts I have tried full path and bare command. Neither of which for either case is making this popup show on the logon screens.
Any and all help and/or advice on this would be greatly appreciated by both myself and my friend.
dynamic display of images for the credential provider
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")
We have built a Mac OSX installer which includes a driver that support some functinalities, hence we need to restart the machine after the installation. However, i wouldn't want to force it, but to allow users to postpone the restart for later (and meanwhile using the software without the driver)
we couldn't find any option for that - something like a message box that would say 'restart' with Now/Later buttons.
any ideas, anyone?
thanks much
Lior
If the user wants to restart "later" then they will restart. If you feel you need to remind them that they need to, then put that reminder in your application, not the installer.
Windows Installer does what you're talking about, a constant pop-up every few hours with "Would you like to restart now? [even though you said no the last 20 times I bugged you]". It's horrible. Don't do it. If the user says later, then they mean later. Don't bug them.
If they try to use a feature in your app that requires the restart, then you can tell them that feature is unavailable until after a restart. Otherwise, no bugging please.