Re: Where to store things in the registry.

Actually, this is probably a bad approach.

How do I enumerate the installed fonts in MFC ?

some rather crude
DRM, by preventingyou from accessing virtual memory in the process, a sad
attempt to block
out capturing the plaintext buffer before it is played

microsoft.public.vc.mfc will be finally removed this autumn (maybe it
has already been removed on Microsofts servers), so I would recommend
staying here.

Regarding the original question, MFC does AFAIK not provide any service
specific classes, but it is not so complicated to control services via
the Windows API:

OpenSCManager
OpenService
StartService
ControlService
QueryServiceStatus
CloseServiceHandle

Bye,
    Daniel

statement is working fine

fprintf (stderr, "Failed FormatMessage - MessageIndex = <%d>.\n", 0);

but when I run this on vc9(visual studio 2008)
an exception is thrown,How to handle the exception is the issue.
The exception condition will occur definitely but handling that is
what I need.In vc6 same code is working fine.

Any one please Help it is very urgent to solve the exception.

On Tuesday, February 23, 2010 4:36 AM
Giovanni Dicanio wrote:

What is the exception thrown?
What is the exception thrown?

The general way of catching exceptions in C++ is by using try/catch, i.e.

try {
...
code
...
}
catch( const std::exception & e ) {
std::cerr << "*** ERROR: " << e.what() << std::endl;
}

Giovanni

On Tuesday, February 23, 2010 4:58 AM
RaG wrote:

4-46c8-9bd1-b6f850644880@f29g2000yqa.googlegroups.com...
4-46c8-9bd1-b6f850644880@f29g2000yqa.googlegroups.com...

exception handling already there, but still the below exception is
comming
First-chance exception at 0x7c91b21a in unittest.exe: 0xC0000005:
Access violation writing location 0x00000010.

On Tuesday, February 23, 2010 6:00 AM
Goran wrote:

No, not really.
No, not really. If you "handle" the exception, your code still does not
work ;-). I think it is better to fix the problem at the origin.

I just tried, this works:

int _tmain(int argc, _TCHAR* argv[])
{
fprintf(stderr, "Failed FormatMessage - MessageIndex = <%d>.\n", 0);
return 0;
}

You should provide here a working example of what is not working ;-).

Alternatively, you can step into fprintf and look at what it does, or,
in Debug->Exceptions, Check "Win 32 Exceptions" under thrown and debug
with that. That will stop in debugger when exception is thrown. Look
at stack trace and at variable values for "unusual" things.

Goran.

On Tuesday, February 23, 2010 6:32 AM
Ismo Salonen wrote:

RaG wrote:My crystall ball tells me that stderr is not open.
RaG wrote:

My crystall ball tells me that stderr is not open. Is the program a
console application ? Normal windows applications need to freopen stderr
themselves.

ismo

On Tuesday, February 23, 2010 8:01 AM
RaG wrote:

2654-46c8-9bd1-b6f850644880@f29g2000yqa.googlegroups.com...);.e.
2654-46c8-9bd1-b6f850644880@f29g2000yqa.googlegroups.com...
);
.e.

My application is multithreaded windows appilcation,In the worker
thread the below statement
if ( (RetCode = DoFormatMessage ( pMFormat, pVariables, pOutString,
MaxStringLength, MaxBufferLength, MessageType )) != SUCCESS )
// tprintf (stderr, "Failed FormatMessage - MessageIndex = <%d>.\n",
fprintf (stderr, "Failed FormatMessage - MessageIndex = <%d>.\n",
0); is crashing the stderr value is Junk , I think "stderr" defaultly
set,The fprint statement is working fine in sample test application .

On Tuesday, February 23, 2010 11:11 AM
Joseph M. Newcomer wrote:

I am very certain that "an" exception is *not* thrown.
I am very certain that "an" exception is *not* thrown. I am, however, absolutely certain
that there is an exception, whose location is precisely identified, down to the line of
code, and the exception type is named. And, if you enter the debugger, you will see that
source code, you will see the values related to the failure, you can examine the stack
backtrace, and you can analyze what has happened. And it could also be a runtime error,
or an assertion failure. Too many people report "exception" when they mean either of the
preceding actual causes. The message that comes out has text in it. Without that text,
and the stack backtrace, and several lines of the code, there is no way to tell you what
went wrong.

You only show one line here; it is very likely that the line preceding it was the cause of
the error. Lacking the detailed information and the stack backtrace, I can only guess,
but my first guess is that the line preceding it is a FormatMessage, and you probably have
an erroneous parameter. Note that modern compilers are sometimes much less forgiving of
user errors than older compilers. For example, stack overwrites. Modern compilers will
detect errors that VS6 never bothered to look for, and thus your code may have *always*
been incorrect, but it simply was not detected before!

The way you "handle" the exception is to fix the error in your program that is causing it.
But since we do not know what the exception is, or where it came from, there is no way to
answer this question.
joe

Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

On Tuesday, February 23, 2010 11:19 AM
Joseph M. Newcomer wrote:

See below....****STOP RIGHT THERE!
See below....

****
STOP RIGHT THERE! WHY ARE YOU DOING AN fprintf TO stderr IN A WINDOWS APP? IT DOESN'T
EXIST!

(Also, what led you to believe that fprintf is thread-safe? It turns out it is, but did
you *really* know that?)

The program was *always* wrong; VS6 probably ignored the statement, but modern compilers
just go ahead and try to use it. Because they know that nobody would be silly enough to
try to write to stderr from a Windows program, so whatever you are asking must be
reasonable, so go ahead and do it anyway.
****
****
And it writes the data where? There is no stderr stream in a Windows app, ever! So I
really doubt that it is "working just fine". I suspect it fails silently. I have NEVER
seen it work in a Windows app, because there *is* no stderr stream it can possibly write
to!

The correct code would have been, for a console app,

_ftprintf(stderr, _T("Failed FormatMessage - MessageIndex = <%d>\n");

As already pointed out, it would be pretty obvious if you had entered the debugger; you
would have seen that stderr is NULL. But why would you expect stderr to exist?

I do not believe that stderr=='Junk'. It most likely is NULL, given the exception. This
is what you *should* expect it to be!
joe
*****
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

On Tuesday, February 23, 2010 1:25 PM
Tom Serface wrote:

Hi Joe,I suspect you are right in this case, but I have found it useful to
Hi Joe,

I suspect you are right in this case, but I have found it useful to protect
file based operations with exception handling code since it does not really
slow it down much and some of the SDK functions will throw exceptions in
exceptional conditions. At least if I catch it I can log the reason and my
customer can tell me more about what happened. Sometimes they are access
problems, sometimes things like disk full, etc.

Tom

On Tuesday, February 23, 2010 2:02 PM
Joseph M. Newcomer wrote:

CFile operations need to be protected with a try/catch block because they
CFile operations need to be protected with a try/catch block because they really ARE
defined to throw C++ exceptions, specifically, CFileException.

As you point out, when there are cases where it really can throw an exception, that is, a
low-level hardware exception such as 0xC0000005, you need to protect the call with a
_try/_catch block, which is awkard because it plays so poorly with C++.
joe

Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

On Wednesday, February 24, 2010 3:54 AM
Goran wrote:

yWait, what? Are there isome SDK file functions that could throw an SE?
y

Wait, what? Are there isome SDK file functions that could throw an SE?
(I am concerned because Windows would be horrible if e.g. ReadFile,
WriteFile, CreateFile could throw __anything__ under any condition!)

Goran.

P.S. Please tell me it ain't so!

On Wednesday, February 24, 2010 12:11 PM
Joseph M. Newcomer wrote:

CloseHandle definitely will, code 0xC0000008 or 0xC0000009 (I forget which),
CloseHandle definitely will, code 0xC0000008 or 0xC0000009 (I forget which), if you try to
close an invalid handle.

AFAIK, ReadFile, WriteFile and CreateFile can throw exceptions only if you pass an invalid
address into them.
joe

Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

On Wednesday, February 24, 2010 2:28 PM
Giovanni Dicanio wrote:

I used to think that CloseHandle cannot throw an exception (it could returnan
I used to think that CloseHandle cannot throw an exception (it could return
an error code, but not throw an exception).

This seems to confirm that:

http://blogs.msdn.com/oldnewthing/archive/2008/01/07/7011066.aspx

Giovanni

On Wednesday, February 24, 2010 3:36 PM
Joseph M. Newcomer wrote:

Not sure what that article confirms.
Not sure what that article confirms. Even in Vista, and back in NT4, I got this behavior.
Try this simple program:

int _tmain(int argc, _TCHAR* argv[])
{
HANDLE h = ::CreateEvent(NULL, FALSE, FALSE, NULL);
// The call below gives the exception
// First-chance exception at 0x77a45e4f in CloseHandle.exe: 0xC0000008: An invalid
handle was specified.
return 0;
}

I ran it in Vista a few minutes ago and the error text you see is a copy-paste from the
MessageBox.
joe

Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

On Wednesday, February 24, 2010 7:27 PM
David Lowndes wrote:

Isn't that just something you get running under the debugger though?
Isn't that just something you get running under the debugger though?

Modify the code - put a MessageBox after the second CloseHandle, and
run it outside the debugger.

Dave

On Wednesday, February 24, 2010 9:22 PM
Joseph M. Newcomer wrote:

Yep.
Yep. The program does not do anything when run in release mode, except that the second
CloseHandle returns FALSE.
joe

Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

On Thursday, February 25, 2010 2:55 AM
Goran wrote:

h), if you try tou pass an invalidWow, our code here must be good, I have
h), if you try to
u pass an invalid

Wow, our code here must be good, I have never seen C0000008 coming out
of it! (More like, we probably try to close valid,
INVALID_HANDLE_VALUE or NULL handles, for whom nothing is thrown). But
e.g CloseHandle(123456) indeed breaks down hard on my machine (just
tried).

But That said, all of the situations you listed are OK in my book. If
I pass invalid handle/address, I have a bug already, so I will actually
thank Windows for kindly :-) pointing it out.

Goran.

On Thursday, February 25, 2010 4:20 AM
Giovanni Dicanio wrote:

And this was the point of the aforementioned article, I think.Giovanni
And this was the point of the aforementioned article, I think.

Giovanni

On Thursday, March 04, 2010 8:21 AM
RaG wrote:

tHi, I am using c dll in a win32 application, so when control comes
t

Hi, I am using c dll in a win32 application, so when control comes to
fprintf(stderr) of the c dll code it is crashing.. can any one tell
why.How to solve this problem

On Thursday, March 04, 2010 2:31 PM
David Ching wrote:

More precisely: Windows itself captures the last chance exception so thatit
More precisely: Windows itself captures the last chance exception so that
it is not exposed to the user. The debugger was catching the first chance
exception.

-- David

On Friday, March 12, 2010 12:33 PM
sm wrote:

"RaG" wrote:
"RaG" wrote:

Submitted via EggHeadCafe - Software Developer Portal of Choice
AJAX Web Service Driven Customers Table With Customer Details
http://www.eggheadcafe.com/tutorials/aspnet/4c3d2726-d99e-4f83-9e49-0d4867b6271a/ajax-web-service-driven-customers-table-with-customer-details.aspx