WriteFile(...) exception

Windows XP Pro, Visual Studio 2008, MFC application.
When I call

Code:

---

WriteFile( m_log_file_handle, &m_log_message, m_write_length, mp_bytes_written,
                NULL );

---

I wind up in the debugger about 13 levels deep and do not understand what it is trying to tell me.

My solution is:

Code:

---

try{
  WriteFile( ... );
  }
catch
  {
  // need help here
}

---

I don't know what can be thrown and my Visual Studio help for WriteFile says nothing about exceptions. What can I put in the catch section to give me a clue as to what it does not like about my WriteFile call.

Have you checked the values of the parameters when you get the crash?

WriteFile is a C function from Windows API.
C language has not a clue about C++ exceptions.

Well, I thought I had the parameters right. So I changed my declarations to:

Code:

---

DWORD m_bytes_written;
LPDWORD mp_bytes_written;
...
<constructor>
mp_bytes_written = &m_bytes_written;
...
WriteFile( ..., mp_bytes_written, ... )

---

and now it works.

However, that still leaves me with the open question, how do I catch a general exception and determine what went wrong?
Ok, given WriteFile does not know anything about expceptions, but Visual Studio does. How do I get it to tell me why it is throwing the exception.

(ps, I tried a search of this site. I am on an Air Force installation and this computer thows up a forbidden page alert. My google searches did not discover a general answer.)

Quote:

---

Originally Posted by bkelly

Well, I thought I had the parameters right. So I changed my declarations to:

Code:

---

DWORD m_bytes_written;
LPDWORD mp_bytes_written;
...
<constructor>
mp_bytes_written = &m_bytes_written;
...
WriteFile( ..., mp_bytes_written, ... )

---

and now it works.

---

Why did you need to do all of this just to pass an address of a DWORD?

Code:

---

DWORD m_bytes_written;
WriteFile( ..., &m_bytes_written, ... )

---

Regards,

Paul McKenzie

Quote:

---

Originally Posted by bkelly

I don't know what can be thrown and my Visual Studio help for WriteFile says nothing about exceptions.

---

It isn't WriteFile that threw the exception. The issue is that you probably have an access violation or some other system exception.

Look up Structured Exception Handling (SEH) if you need further information as to how to catch system exceptions.

Quote:

---

How do I get it to tell me why it is throwing the exception

---

If you're debugging your code, look at the Output Window. It will state the reason for the exception. Also, you should see numbers like 0xC00000005, telling you what the exception is.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by Paul McKenzie

Why did you need to do all of this just to pass an address of a DWORD?

Code:

---

DWORD m_bytes_written;
WriteFile( ..., &m_bytes_written, ... )

---

Regards,

Paul McKenzie

---

No valid reason. I just saw the LPDWORD in the help file and declared that without thinking, then had to declare the pointer, ....
Thanks for the comment.

Regarding the output window, it just said something like no more endpoints and nothing of value to me. I still wish to know how to catch the exception and put up some type of decent error messages. The Catch( ...) should work, but where do I find the reason for the thrown exception?

Quote:

---

Originally Posted by bkelly

Regarding the output window, it just said something like no more endpoints and nothing of value to me.

---

Maybe it is of great value to the ones helping you here. Please post what the output window is stating concerning the exception.

Quote:

---

The Catch( ...) should work, but where do I find the reason for the thrown exception?

---

Again, look up Structured Exception Handling.

Regards,

Paul McKenzie

re: Again, look up Structured Exception Handling.

Ok, in progress.

Maybe a re-direct is warrented. I need to write a log file in a real time application. (It processes telemetry data and really is real time.) The environemnt is Visual Studio 2008, MFC, and C++. A search got me going with:

CreateFileA(...)
and
WriteFile(...)

Is this a good approach for text based log file in an MFC application? Would something like this be better:

StreamWriter^ sw = gcnew StreamWriter(fileName);

I found that in an MSDN web page.

Thanks for your time.

Quote:

---

Originally Posted by bkelly

...
Is this a good approach for text based log file in an MFC application? Would something like this be better:

Code:

---

StreamWriter^ sw = gcnew StreamWriter(fileName);

---

I found that in an MSDN web page.

---

This code has nothing to do with an MFC application. Nor is it a native C++ code.
Microsoft developed a lot of new languages and/or language extensions, and so called "managed C++/CLI" is one of them.

Quote:

---

Originally Posted by VictorN

This code has nothing to do with an MFC application. Nor is it a native C++ code.
Microsoft developed a lot of new languages and/or language extensions, and so called "managed C++/CLI" is one of them.

---

Interesting. A google search for the phrase:
write text file mfc c++
Noting I specifically included "mfc" and "C++" in my search, turned up this page:
http://msdn.microsoft.com/en-us/libr...(v=vs.80).aspx
and there under the title File Handling with Visual C++ is a section on writing text files, that links to here: http://msdn.microsoft.com/en-us/libr...(v=vs.80).aspx and says to use that. So I got there with what appears to be a fully legimitate search.

But as I read your post, you say Nay.
OK, please suggest a specific method that I should use to write my text file. Do you have a link to your favorite page that gives some example code?

Quote:

---

Originally Posted by bkelly

Maybe a re-direct is warrented. I need to write a log file in a real time application. (It processes telemetry data and really is real time.)

---

What Windows OS are you building for? Windows desktop OS'es are not real-time operating systems.

Quote:

---

Would something like this be better:
StreamWriter^ sw = gcnew StreamWriter(fileName);

---

Hate to break it to you, but that code is not C++.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by Paul McKenzie

What Windows OS are you building for? Windows desktop OS'es are not real-time operating systems.
Hate to break it to you, but that code is not C++.

Regards,

Paul McKenzie

---

Paul,
Yes, I am fully aware that windows is not real time. However, companies like Wyle TDS (Telemetry and Data Systems, well known in the telemetry business) build their telemetry system under Windows XP Pro and companies like Symvionics build their display systems called IADS (Interactive Analysis and Display System, again well known in the telemetry business) under Windows XP Pro. Both serve a real time purpose and are used real time, and I must deal with them. And now both are migrating to Windows 7. Still not a real time system, but that is what the vendors use.

A template application provided by Wyle TDS to use as a starter application uses MFC to fetch data from their decommutation system so that is the foundation of my code to grab data, process it, and forward it to IADS.

Evidently my search yielded some results that are not fully appropriate for the MFC environmet.

So what should I use to open and write a text based log file?

Quote:

---

Originally Posted by bkelly

So I got there with what appears to be a fully legimitate search.
But as I read your post, you say Nay.

---

This forum deals with C++ as described by the ANSI/ISO standard, with emphasis on the Visual C++ compiler and libraries (MFC, ATL).

That code you have is not ANSI C++. Try to take that code and compile it in an MFC or Win32 project. You will get errors galore.

Code:

---

StreamWriter^ sw = gcnew StreamWriter(fileName);

---

There is no such thing as "gcnew", or the "^" character next to the type like that in ANSI C++. In C++, the only use for "^" is for the XOR operation (unless you overload it to do something else).

Regards,

Paul McKenzie

Well, CreateFile and WriteFileWindows API should (I'd say must) work good if you used them right.
What exactly is your problem? Why don't you want to show your actual code producing the problems?
Did you try something with SEH as Paul suggested?

Quote:

---

Originally Posted by bkelly

...Evidently my search yielded some results that are not fully appropriate for the MFC environmet.

So what should I use to open and write a text based log file?

---

CStdioFile

Quote:

---

Originally Posted by bkelly

So what should I use to open and write a text based log file?

---

CreateFile and WriteFile are the common functions to use to create and write a file in Windows OS. MFC has specialized classes that wrap this functionality such as CFile and CStdioFile, so CStdioFile would be the best bet.

And of course, you have the general C++ functions such as ifstream/ofstream, as well as fopen/fclose, but remember that these are standard C++ functions -- meaning they do not have all the bells and whistles of the Windows API and MFC classes/functions.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by VictorN

Well, CreateFile and WriteFileWindows API should (I'd say must) work good if you used them right.
What exactly is your problem? Why don't you want to show your actual code producing the problems?
Did you try something with SEH as Paul suggested?

---

Structured Exception Handling:
Yes, I am looking at that. but, for example, the declaration for WriteFile does not say anything about any exceptions so I still don't know what to do in the catch handler to determine the source of a problem.

Switching to topic CreateFileA() and WriteFile()

Well, they are working now. Reading this thread and thinking about the posts led me to the errors in my code.

That done, I have several classes and now need to log data from multiple classes. That means I need extract my logging code, that started out simple, to a new class that is accessible to several classes so I can coordinate the logging data.

Now that I am doing that, I am wondering if I have selected the right tool for this job. As noted earlier, even a search that specified "mfc C++" turned up options that are not appropriate for MFC. I don't have any co-workers that have that knowledge, so here I am.

Given all the above, Windows XP Pro, soon migrating to Windows 7, Visual Studio 2008, MFC, C++:

What is the best tool to use for writing a text based log file?

Quote:

---

Originally Posted by bkelly

Structured Exception Handling:
Yes, I am looking at that. but, for example, the declaration for WriteFile does not say anything about any exceptions so I still don't know what to do in the catch handler to determine the source of a problem.

---

The WriteFile() function doesn't have to say anything about exceptions because WriteFile doesn't throw any exceptions.

For example, here is a function:

Code:

---

void foo(char *p)
{
    *p = 'x';
}

---

What if you pass an invalid pointer to foo()? What will happen? The foo function throws no exceptions, as you don't see the throw keyword used anywhere. The system exception that may occur would be a memory access violation. Those exceptions are called system exceptions -- they are not to be confused with general C++ exceptions.

So you cannot just look at the traditional try/catch that C++ provides, since they are meant to catch C++ exceptions. A C++ exception is one where the function you're calling actually throws an exception using the throw keyword. My foo() function doesn't throw exceptions, and neither does WriteFile, so it would be erroneous for WriteFile to mention anything about exceptions being thrown.

Structured Exception Handling (SEH) is a topic that is a different issue altogether. A Structured Exception is not a C++ topic, it is a Windows OS topic. Please read fully what Structured Exceptions are, and how to handle them. What programmers will do is set up the SEH, and then from that SEH handler, throw a real C++ exception using the throw keyword. Also, Visual C++ introduced keywords (I've never used them) that handle these types of exceptions, different than try/catch:

http://msdn.microsoft.com/en-us/libr...(v=vs.80).aspx

Regards,

Paul McKenzie

RE: So you cannot just look at the traditional try/catch that C++ provides, since they are meant to catch C++ exceptions. A C++ exception is one where the function you're calling actually throws an exception using the throw keyword. My foo() function doesn't throw exceptions, and neither does WriteFile, so it would be erroneous for WriteFile to mention anything about exceptions being thrown.


Ok, that was a learning moment. I now understand that when I called the WriteFile() and wound up in an unhandled exception environment (running the program from within the Visual Studio environment), that was because of my C/C++ fundamental error, and not the result of the WriteFile(). So putting a try/catch around WriteFile and its brethern has no merit.

So, that lesson learned, what should I use to create and write to a text based log file from within an MFC project?

There are some logging libraries on the net (google 'c++ logging library').

I've only used ACE (http://www.cs.wustl.edu/~schmidt/ACE.html) but that might be to overcomplicate things. This http://www.pantheios.org/ or this http://log4cpp.sourceforge.net/ might be more lightweight versions.

Quote:

---

Originally Posted by bkelly

...
So, that lesson learned, what should I use to create and write to a text based log file from within an MFC project?

---

See the post#17. :cool:

Quote:

---

Originally Posted by bkelly

Ok, that was a learning moment. I now understand that when I called the WriteFile() and wound up in an unhandled exception environment (running the program from within the Visual Studio environment), that was because of my C/C++ fundamental error, and not the result of the WriteFile(). So putting a try/catch around WriteFile and its brethern has no merit.

---

Well, the problem is that you can do something like this:

Code:

---

try
{
  WriteFile(..);
}
catch(...)
{
   
}

---

And that could catch the system exception if you compile with the /EHa switch. However, the problem is the catch-all "..." phrase, as you don't know exactly what happened. So yes, you can catch the exception, but have little information as to what the exception is.

That's why IMO it's better to use the Visual C++ keywords I mentioned, or set up the SEH "the hard way", get the real error, and from your SEH, do a legitimate C++ throw with better information as to the error. These options do not need special compiler switches set to work.

See here:

http://msdn.microsoft.com/en-us/libr...(v=vs.80).aspx

Regards,

Paul McKenzie

Quote:

---

Originally Posted by VictorN

See the post#17. :cool:

---

In the flurry of posts I kept scrolling to the bottom, failed to look carefully, and missed that one.
Thank you.