Statically Linked MFC app (VC 7.1) won't run from CD
Todd Brooks
EA) that refuses to run from CD. I copy the EXE to a Read-Only directory on
my hard drive, mark it as read-only and it will run. But if I copy the EXE
to a CD and run from the CD drive, it refuses with the following error:
"Runtime Error!
This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information."
My application is a MFC application that also uses the Stencil Processor
from ATL Server.
I thought I had all my Release Build compiler and linker settings correct,
but I guess not. I made sure and set the following:
Use of MFC: Use MFC in a Static Library
Use of ATL: Static Link to ATL
Minimize CRT Use in ATL: No
Character Set: Use Multi-Byte Character Set (this app has to work on Win9x)
Use Managed Extensions: No
I even made sure that /SWAPRUN was set for CD and NET, but even eliminating
those didn't fix the problem.
Compiler Command Line:
/O1 /GL /GA /I "../../Blah/Source/Shared Lib/Asset_LIB"
/I "../../Blah/Source/Shared_Lib/include" /D "WIN32" /D "_WINDOWS" /D
"NDEBUG" /D "_MBCS" /D "_ATL_STATIC_REGISTRY" /FD /EHsc /MT /GS /Zc:wchar_t
/Yu"stdafx.h" /Fp"Release/Blah.pch"
/Fo"Release/" /Fd"Release/vc70.pdb" /W4 /nologo /c /Wp64 /TP
Linker Command Line:
/OUT:"Release/Blah.exe" /INCREMENTAL:NO /NOLOGO /DELAYLOAD:"OleAcc.dll"
/SUBSYSTEM:WINDOWS
/SWAPRUN:CD /SWAPRUN:NET /OPT:REF /OPT:ICF /LTCG /MACHINE:X86 delayimp.lib
DelayImp.lib DelayImp.lib
While I am doing file handling in my application, I made sure the code path
for this EXE is not trying to create or write to any files on the CD.
Any ideas why it will not run from CD?
Regards,
todd brooks
Mike Deakins
CD-ROM.
Please check the Stencil Processor component.
Also, what if you compile it in Debug mode? If Debug mode can not run from
CD-ROM either, you can start a debugger and trace the error.
--
Mike J. Deakins
For the shining star in my skies.
Nishant Sivakumar
the executable or on a relative path (perhaps using CFile or CStdioFile) and
then without making sure that the file has been created you might be trying
to write to it. Obviously this will fail on a CDROM but will work on a hard
disk.
--
Regards,
Nish [VC++ MVP]
"Todd Brooks" <tbr...@no.spam.thecodefoundry.com> wrote in message
news:#0EMiqpH...@TK2MSFTNGP10.phx.gbl...
Todd Brooks
The code snippet below is what is causing the application to not run from
the CD
The file it is trying to load (m_configFile) is already on the CD.
Does CArchive have some kind of weird write permission requirement that I'm
not aware of?
CFile file;
CFileStatus status;
if (CFile::GetStatus(m_configFile.c_str(), status)){
// File exists
if (file.Open(m_configFile.c_str(), CFile::modeRead)){
// File opened; load data
try{
CArchive archive(&file, CArchive::load);
Serialize(archive);
archive.Close();
file.Close();
}
catch(CArchiveException* err){
// Unable to load the file due to probably incorrect version
file.Close();
//file.Remove(m_configFile.c_str());
err->Delete();
return FALSE;
}
// Loaded successfully
return TRUE;
}
else
// File can't be opened...reason unknown
return FALSE;
}
else{
// File doesn't exist
return FALSE;
}
Yan-Hong Huang[MSFT]
Each MFC and ATL code has source code in the disk. I think it is much
quicker if you could debug the program or add some print statement to the
program and then isolate the problem to a single line of code.
Best regards,
yhhuang
VS.NET, Visual C++
Microsoft
This posting is provided "AS IS" with no warranties, and confers no rights.
Got .Net? http://www.gotdotnet.com
--------------------
!From: "Todd Brooks" <tbr...@no.spam.thecodefoundry.com>
!References: <#0EMiqpH...@TK2MSFTNGP10.phx.gbl>
!Subject: Re: Statically Linked MFC app (VC 7.1) won't run from CD
!Date: Tue, 20 May 2003 11:37:22 -0500
!Lines: 42
!X-Priority: 3
!X-MSMail-Priority: Normal
!X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
!X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
!Message-ID: <eXyBY4uH...@TK2MSFTNGP11.phx.gbl>
!Newsgroups:
microsoft.public.dotnet.languages.vc,microsoft.public.dotnet.languages.vc.li
braries
!NNTP-Posting-Host: cs242798-153.houston.rr.com 24.27.98.153
!Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP11.phx.gbl
!Xref: cpmsftngxa06.phx.gbl
microsoft.public.dotnet.languages.vc.libraries:2093
microsoft.public.dotnet.languages.vc:24009
!X-Tomcat-NG: microsoft.public.dotnet.languages.vc
!
!I've been able to narrow down where it is failing, though trial and error.
!The code snippet below is what is causing the application to not run from
!the CD
!The file it is trying to load (m_configFile) is already on the CD.
!
!Does CArchive have some kind of weird write permission requirement that I'm
!not aware of?
!
!CFile file;
!CFileStatus status;
!
!if (CFile::GetStatus(m_configFile.c_str(), status)){
! // File exists
! if (file.Open(m_configFile.c_str(), CFile::modeRead)){
! // File opened; load data
! try{
! CArchive archive(&file, CArchive::load);
! Serialize(archive);
! archive.Close();
! file.Close();
! }
! catch(CArchiveException* err){
! // Unable to load the file due to probably incorrect version
! file.Close();
! //file.Remove(m_configFile.c_str());
! err->Delete();
! return FALSE;
! }
!
! // Loaded successfully
! return TRUE;
! }
! else
! // File can't be opened...reason unknown
! return FALSE;
!}
!else{
! // File doesn't exist
! return FALSE;
!}
!
!
!
Todd Brooks
simple MFC dialog test app. In the app::InitInstance I placed this code:
CFileStatus status;
CString filename = "E:\\Report.txt"; // This is a file on a CD in the drive
try{
int x = CFile::GetStatus(filename, status);
}
catch(CException* err){
TCHAR szCause[255];
CString strFormatted;
err->GetErrorMessage(szCause, 255);
AfxMessageBox(CStringA(szCause)); // Displays error
}
catch(...){
AfxMessageBox("fell through");
}
The first catch is called (CException)...if I change it to CFileException,
it doesn't get called. The error that is displayed is "The parameter is
incorrect". If I change filename to a file on my hard drive or on a network
drive, NO exceptions are thrown.
Why is this? Is there a bug in GetStatus that is causing this? Am I doing
something wrong?
Regards,
todd
"Yan-Hong Huang[MSFT]" <yhh...@online.microsoft.com> wrote in message
news:PkAHAl1H...@cpmsftngxa06.phx.gbl...
Will Dean
>
> Why is this? Is there a bug in GetStatus that is causing this? Am I
doing
> something wrong?
I've just had a quick play around with this. Although this stepping was
more difficult than necessary, because it seems that the VS2003 MFC
source code doesn't actually match the supplied library, it's clear that
the only thing which could throw the exception is the CTime constructors
used in filling the CFileStatus object.
I would think that something about the way your CDROM is generated has
resulted in invalid timestamp(s) on the files, which are confusing
CTime. If the effect of that is that you can't use CArchive, that's a
bit of a pain, to say the least...
Try and step through the GetStatus call to see which time is actually
causing the problems.
Cheers,
Will
Todd Brooks
"Will Dean" <industria...@nospam.demon.co.uk> wrote in message
news:uBcuZ2DI...@tk2msftngp13.phx.gbl...
> I've just had a quick play around with this. Although this stepping was
> more difficult than necessary, because it seems that the VS2003 MFC
> source code doesn't actually match the supplied library, it's clear that
> the only thing which could throw the exception is the CTime constructors
> used in filling the CFileStatus object.
>
> I would think that something about the way your CDROM is generated has
> resulted in invalid timestamp(s) on the files, which are confusing
> CTime. If the effect of that is that you can't use CArchive, that's a
> bit of a pain, to say the least...
>
Yup, the error happens on line 180 in filest.cpp:
rStatus.m_atime = CTime(findFileData.ftLastAccessTime);
Looks like CDs and DVD media return 0 (zero) for ftLastAccessTime, thus what
actually asserts is the CTime ctor in atltime.inl (line 224) when it tries
to call FileTimeToSystemTime(). The root cause is at the beginning of the
ctor, it tries to convert the first param to a FILETIME struct by calling
FileTimeToLocalFileTime() where the first param is 0. While this function
succeeds, the FILETIME sturct now has garbage data in it.
I've tried this on a CD and a DVD drive and both fail. I even used
commercial CDs (not CD-Rs created by me) and they fail also.
MS: Is this a bug or "by design"?
todd
Will Dean
>
> Yup, the error happens on line 180 in filest.cpp:
> rStatus.m_atime = CTime(findFileData.ftLastAccessTime);
From the line number, you're using VS2003 - do you find that the debug
correctly steps through that file?
On my setup, it doesn't - as though the library it's link against
doesn't match the source.
I feel as though I should worry about this a bit...
> I've tried this on a CD and a DVD drive and both fail. I even used
> commercial CDs (not CD-Rs created by me) and they fail also.
Well, I tried an MSDN DVD (which happened to be in the drive) and it
worked. (WinXP-SP1)
Interesting....
Will
Todd Brooks
Debug AND release builds fail.
And yes, the first time I debugged, the file it was looking for (filest.cpp)
was not the correct path, but changing to the right path and file, it worked
every time after that.
I've tried this same sample code on CDs I've written along with commercial
CDs like MSDN, etc. Results have all been the same. I find it hard to
believe that I'm the first to have encountered this. I would think this
would be a fairly common thing to do (checking for the existence of a
file...in my case it just happened to be in the same path where the
executable was.....on the CD).
todd
David Lowndes
>correctly steps through that file?
>
>On my setup, it doesn't - as though the library it's link against
>doesn't match the source.
I seemed to suffer with that problem - until I removed VS2002. After
that the debugger couldn't locate the old sources and after pointing
it to the VS2003 versions, it's apparently been OK since.
Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq
Will Dean
"David Lowndes" <dav...@mvps.org> wrote in message
news:45spcvstc4ipr5r7b...@4ax.com...
> >From the line number, you're using VS2003 - do you find that the
debug
> >correctly steps through that file?
> >
> >On my setup, it doesn't - as though the library it's link against
> >doesn't match the source.
>
> I seemed to suffer with that problem - until I removed VS2002. After
> that the debugger couldn't locate the old sources and after pointing
> it to the VS2003 versions, it's apparently been OK since.
Hmm. I got the usual request for a file on some bizarre internal MS
build path, and I'm 90% sure I pointed it at the right code. Maybe I
pointed it at 2002 by mistake....
I'll have to dig around to find where that info comes from.
Will
Phil Davidson
around this problem, or should we just avoid using
CFile::GetStatus when the file might reside on CDROM or
DVD-ROM?
-- Phil Davidson
pdav...@riverdeep.net