safe. I put protection around my calls to Create() and that solved
the problem. The real question is why the problem did not show up in
thing. I guess race situations work that way.
On Tue, 09 May 2006 13:43:19 -0400, Joseph M. Newcomer
<newcomer@flounder.com> wrote:
I am sorry to be non-specific but I thought I was describing carefully
just what was happening.
My system was generating a system exception. I thought I did specify
that the failure was specifically in AfxRegisterClass.
In release mode it generates a CResourceException in
AFX_ISOLATIONAWARE_STATICLINE_FUNC(ATOM,
RegisterClassA(const WNDCLASSA*lpWndClass),(lpWndClass),0)
I don't have debug information available for kernel32.dll so I can't
trace it further.
In debug mode the error occurs in AfxRegisterClass in wincore.cpp
line 1365. The error message is
"Can't register window class named xxx"
where the name is lpWndClass->lpszClassName which has a value of
0x0040000. The specific function that faulted is AfxCtxRegisterClass
which I can't trace.
I have now discovered that the actual value of lpszClassName during
the fault condition is 0x0040000 (as mentioned above) while the value
during normal operation is a pointer to the string "Afx:00400000:0".
However, as I mentioned previously, the lpWndClass structure is
something generated entirely within CAsyncSocket and is not of my
doing so I don't know why it should fail.
The code that generates the fault (aka "crash", sorry about that) is
m_pSB = new CSocketBase(this;
// CSocketBase is derived from CAsyncSocket
if (!m_pSB->Create()) {
// handle creation error
}
The fault occurs during Create() which never returns.
The parameters for Create() are the CAsyncSocket default values, as I
did specify in my query.
This code (which I did describe in my query) is located in the
InitInstance() function of a CWinThread derived class.
As I indicated in another post, I am creating a whole series of
sockets using this technique. The fault does not occur in the first
instance, but randomly in later instances. Debug version generates
the fault far less frequently than does release version. With more
than two sockets, the release version faults virtually every time;
with 15 sockets, the debug version faults less than 10% of the time.
Note: I am generating all these instances of my CWinThread derived
class each of which constructs and tries the Create() a CAsyncSocket
in the InitInstance() of my main CWinApp of a mutli-doc MFC app after
showing and updating the CMainFrame. I have also moved the generation
of the CWinThread derived classes to the OnInitialUpdate() of a CView
derived class. Still, it is all occurring prior to the main app Run
begins, if that is the problem.
I am not well enough versed in the internals of MFC doc/view programs
to know exactly when everything is occurring, especially when the
InitInstance of all those CWinThreads being. I strongly suspect a
race condition with the InitInstance of all those threads. As I said
in my original query, the fault is generated only on one of my
hardware platforms, four other computers run the identical release
code with no apparent problem with dozens of not hundreds of trials.
ohhh...a "crash"? WHAT IS A "CRASH"?????
I don't suppose you would actually let us in on what is really happening? Is it a secret?
There is no such thing as "a crash". There may be access faults, which take place not
"deep within CAsyncSocket::Create" but in fact on a very specific line of a very specific
file, or as the result of a call into the Win32 API which was invoked by a very specific
line of a very specific file. Did you have an assertion failure? If so, file and line
information would have been provided.
All you've said here is "my program doesn't work, what did I do wrong?". The answer is:
"Something". If you want a question answered, you can't use a term as meaningless as
"crash" without giving explicit detail about what happened, and preferrably show some
code.
The most useful suggestion is to (a) demonstrate that you are utterly confident you have
correct parameters by making sure that every parameter has been checked for
correctness---a lot of people assume that some operation has succeeded and use its result
without bothering to check for success [we can't tell if you did this because you gave no
code example!] (b) report the EXACT details of the failure so we have a chance of offering
advice.
joe
On Tue, 09 May 2006 10:02:20 -0400, r norman <NotMyRealEmail@_comcast.net> wrote:
I have an application that crashes but only sometimes and only one
some specific hardware. It fails deep within CAsyncSocket::Create,
specifically in Socket/AttachHandle/AfxRegisterClass. The Create call
is made using only the default parameters. I have a CWinThread for
each socket and I construct the CAsyncSocket and call Create() with no
parameters in its InitInstance(). This is a process that I have used
for years without a problem; however this is my first Visual Studio
2005 application.
I am compiling using MFC under Visual Studio 2005. I have two systems
with Windows XP Home, one with XP Professional and one with Windows
2000 that never have a problem and two brand-new XP Professional
systems right out of the box where it always has a problem. I am
using the same Visual Studio 2005-generated setup program to run the
program on all six of my test platforms.
Neither the documentation for AfxRegisterClass nor for
CAsyncSocket::Create even suggest that an exception might be generated
rather than an error return. As far as I can see, the lpWndClass
looks the same whether or not the registration succeeds, that
structure is generated entirely by CAsyncSocket.
Does anybody have any ideas what is happening? I would be very
grateful for any hints or suggestions or guesses on what I could try.
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm