By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
444,017 Members | 1,158 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 444,017 IT Pros & Developers. It's quick & easy.

Why Is Detail Hidden In Private Fields In AccessViolationException

P: n/a
I've written a test harness in C# to test one of our company's products,
which is written in C.

If the application crashes, the Instruction Address, Memory Address and the
Access Type are stored in the private fields _ip, _target and _accessType of
the AccessViolationException that is thrown. I want to be able to report
these errors to the user in the C# harness to assist in writing defect
reports for the development teams.

I can only access these fields using Reflection. My question is why is this
informative information kept in private fields in the exception, and not
available as a public Property? It would also seem to make sense for this
information to be reported in the Message property as well.

If the crash occurs when running the product directly, i.e. in C, this
information is reported by Windows, so it seems at first glance a step
backwards to not report this information when the AccessViolationException is
thrown from the P/Invoke.
Jul 9 '08 #1
Share this Question
Share on Google+
2 Replies


P: n/a
I dont have any code which generates one of these but have you tried looking
in the Data property. Its a dictionary which is sometimes used to give extra
information about the exception.

Let us know if its in there.

--
Ciaran O''Donnell
http://wannabedeveloper.spaces.live.com
"Tristan MSDN Keen" wrote:
I've written a test harness in C# to test one of our company's products,
which is written in C.

If the application crashes, the Instruction Address, Memory Address and the
Access Type are stored in the private fields _ip, _target and _accessType of
the AccessViolationException that is thrown. I want to be able to report
these errors to the user in the C# harness to assist in writing defect
reports for the development teams.

I can only access these fields using Reflection. My question is why is this
informative information kept in private fields in the exception, and not
available as a public Property? It would also seem to make sense for this
information to be reported in the Message property as well.

If the crash occurs when running the product directly, i.e. in C, this
information is reported by Windows, so it seems at first glance a step
backwards to not report this information when the AccessViolationException is
thrown from the P/Invoke.
Jul 9 '08 #2

P: n/a
I've looked in the Data property, and it has a count of 0.

"Ciaran O''Donnell" wrote:
I dont have any code which generates one of these but have you tried looking
in the Data property. Its a dictionary which is sometimes used to give extra
information about the exception.

Let us know if its in there.

--
Ciaran O''Donnell
http://wannabedeveloper.spaces.live.com
"Tristan MSDN Keen" wrote:
I've written a test harness in C# to test one of our company's products,
which is written in C.

If the application crashes, the Instruction Address, Memory Address and the
Access Type are stored in the private fields _ip, _target and _accessType of
the AccessViolationException that is thrown. I want to be able to report
these errors to the user in the C# harness to assist in writing defect
reports for the development teams.

I can only access these fields using Reflection. My question is why is this
informative information kept in private fields in the exception, and not
available as a public Property? It would also seem to make sense for this
information to be reported in the Message property as well.

If the crash occurs when running the product directly, i.e. in C, this
information is reported by Windows, so it seems at first glance a step
backwards to not report this information when the AccessViolationException is
thrown from the P/Invoke.
Jul 11 '08 #3

This discussion thread is closed

Replies have been disabled for this discussion.