|
From: Clay Jones on 9 May 2008 18:05 Application Description: The Application is a MFC C++ unmanaged code application, which utilizes Visual Studio .Net 2003 to compile and InstallShield Version 12 to deploy. The application is intended to be installed on the following Operating Systems: Windows 2000 sp4; Windows XP sp2; and Windows Vista. Problem Description: On Windows Vista, once installed the application executes as expected one or two times then a failure occurs for every execution thereafter. The security feature UAC, User Access Control, is enabled before and after installation, and the installation is performed using an account with Administrator rights. Performing "Run as Administrator" on the right click menu does not resolve the problem and the same error occurs. The error that occurs is "ImageDeposit MFC Application has stopped working." See figure below. The crash details are as follows: Problem signature: Problem Event Name: APPCRASH Application Name: ImageDeposit.exe Application Version: 4.3.0.3 Application Timestamp: 46d59493 Fault Module Name: Secur32.dll Fault Module Version: 6.0.6000.16386 Fault Module Timestamp: 4549bdd2 Exception Code: c0000005 Exception Offset: 000021f4 OS Version: 6.0.6000.2.0.0.768.3 Locale ID: 1033 Additional Information 1: 282b Additional Information 2: 96f82c9a65b406a6ce9e9400f8545391 Additional Information 3: 0afc Additional Information 4: 5f929daafffe194e86eb6223007ccac0 Current Work-Around: At this time, using a batch file that copies the executable and executes that copy appears to be an effective means of running the application as expected. However, due to the somewhat technical means of implementing the work-around, a tech-support technician must make the necessary adjustments to each installation on Windows Vista. We have attempted to run the application as Elevated with no success. Any other suggestions would be greatly appreciated.
From: David Lowndes on 10 May 2008 04:37 >Problem Description: > >On Windows Vista, once installed the application executes as expected one or two times then a failure occurs for every execution thereafter. >... Run it under the debugger and find where it's crashing. If you don't want to install a development environment on the machine, use the remote debugger facilities. Dave
From: David Ching on 10 May 2008 13:52 "Clay Jones" <sadf> wrote in message news:OpVM1CisIHA.5724(a)TK2MSFTNGP06.phx.gbl... > On Windows Vista, once installed the application executes as expected one > or two times then a failure occurs for every execution thereafter. > The security feature UAC, User Access Control, is enabled before and after > installation, and the installation is performed using an account with > Administrator rights. Performing "Run as Administrator" on the right > click menu does not resolve the problem and the same error occurs. If the app runs correctly even once (which it does), it's not a problem with UAC. As others have suggested, you should handle this as a normal crash and debug accordingly. -- David
From: Joseph M. Newcomer on 11 May 2008 00:49 Well, not quite true. Two scenarios: If UAC is enabled, different paths are used internally, and one of these has a bug that causes secondary memory damage which may or may not be detected on a single run. If UAC is enabled, some APIs may fail, thus not initializing values that should be initialized, but which are used. Depending on other usage patterns, the uninitialized values may cause damage which is detected only on some machines under some circumstances. I've seen C code that failed if the user name was exactly 12 characters long (no, I didn't write it...) joe On Sat, 10 May 2008 10:52:41 -0700, "David Ching" <dc(a)remove-this.dcsoft.com> wrote: >"Clay Jones" <sadf> wrote in message >news:OpVM1CisIHA.5724(a)TK2MSFTNGP06.phx.gbl... >> On Windows Vista, once installed the application executes as expected one >> or two times then a failure occurs for every execution thereafter. >> The security feature UAC, User Access Control, is enabled before and after >> installation, and the installation is performed using an account with >> Administrator rights. Performing "Run as Administrator" on the right >> click menu does not resolve the problem and the same error occurs. > >If the app runs correctly even once (which it does), it's not a problem with >UAC. As others have suggested, you should handle this as a normal crash and >debug accordingly. > >-- David > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Bob Moore on 13 May 2008 17:05 On Fri, 9 May 2008 17:05:20 -0500, Clay Jones wrote: > Fault Module Name: Secur32.dll We had problems with several apps randomly crashing in this DLL (which have all worked fine for years in both 2000 and XP), and most likely cuplrit seems to be the legacy installer detection code in Vista. Every so often LID thought that we had done something that made us look a bit like an installer... and bang. Silly me just expected an elevation dialog, but it seems life's not that simple. In two cases, simply changing the base module name of the app would stop this happening (changing the executable filename isn't enough, it took a recompile of the source inside a new project with a different name, but nothing else changed). But don't go expecting MS to share the detailed characteristics that LID uses to reach its decisions. This affected three apps in total, two with "launcher" as part of their name, and one with "setup". Same secur32.dll crashes in each. We recompiled two apps with new names and the problem went away. At the third app I lost patience and declared that entire version of the system not compatible with Vista. Partially because I didn't want to go on supporting it in an unpredictable environment, but mostly because I don't want to be seen to be propping up the polished turd that is Vista. But then we have another application called AutoUpdate that trips LID, but that works fine and just produces an elevation dialog. The only common factor among the three crashers was that they launched other apps, and looked a bit like installers (and that they all worked fine up till Vista shipped). UAC is actually not a bad idea (minimal privilege has always been a good idea), its just the current implementation that sucks. -- Bob Moore http://bobmoore.mvps.org/ (this is a non-commercial site and does not accept advertising) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Do not reply via email unless specifically requested to do so. Unsolicited email is NOT welcome and will go unanswered. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
Next
|
Last
Pages: 1 2 3 4 Prev: HTML Help Redistribution Next: Unable to run MFC app on Vista with UAC enabled |