OK, maybe my comment was not technically correct according to some stricter
for an array can cause this sort of error. I've seen this in programs lots
of times. I do believe the OS protects itself against some sorts of memory
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
There is no concept of memory "outside the user's program" to be
protected. The process
defines the memory that is accessible, and therefore all of it is "inside"
the user's
program.
One reason for failure could be an API that, without UAC, returns a valid
value, but under
UAC returns NULL, or one which returns BOOL which always returns TRUE
without UAC but
returns FALSE if UAC is enabled, but then doesn't modify memory in an
appropriate fashion.
For example
TCHAR SillyFixedBuffer[SOME_SIZE];
SomeApi(SillyFixedBuffer);
with UAC enabled, the character buffer is not initialized, so the
subsequent
_tcscpy(SomeOtherPlace, SillyFixedBuffer);
is copying an unterminated buffer and clobbering everything in sight,
whereas if the
buffer had been filled in there would have been no buffer overrun.
A good start would be to replace all the unsafe copies with either
VS2005/2008 _tsccpy_s,
or for older environments, using strsafe.h and doing StringCchCopy.
Similarly for
strcats. Looking for fixed buffers and failures to test APIs that might
fail would be
important also.
Using App Verifier to test for memory overruns and such would not be a bad
start.
What is apalling about the crash diagnostic shown is that the most
important piece of
information, the program counter, is not displayed, nor is the register
set. Vista really
is a POS in terms of post-mortem analysis. If a "crash dump" is produced,
it should be
analyzed by the debugger to try to derive useful factoids like the
register set (including
program counter) and call stack.
joe
On Sat, 10 May 2008 06:14:51 -0700, "Tom Serface"
<tom.nospam@camaswood.com> wrote:
A c0000005 exception sounds like you may have a place in your code that is
accessing memory beyond the end of an array or with an uninitialized
pointer
or something like that. Is there a chance that you have a string
somewhere
that has a chance of not being null terminate? Maybe this just happens to
work on XP or Win2K because they are not as rigorous at protecting memory
outside of the user's program. You would, of course, relax this kind of
security by running as Admin or without UAC, but there may be a real bug
that you're just missing.
If you have an idea what the program is doing right before it stops you
could put in log entries around that area to try to pin down where the
problem is occurring.
Tom
"Clayton" <lcajones@yahoo.com> wrote in message
news:OMj1xFisIHA.5580@TK2MSFTNGP04.phx.gbl...
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 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,
imagedeposit.exe, 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.
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm