From: Clay Jones on
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
>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
"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
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
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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~