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?