New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FatalExecutionEngineError debugging and FailFast #1137
Comments
can we just clear up one point to avoid confusion
the error+stacktrace of the root exception is not shown in the configured log because of an error in config. |
@SimonCropp Apparently not when debugging in the IDE. I get no entry at all, let alone a stack trace. When running without debugging, I do get 3 entries in the log, but the original stack is lost. Perhaps it's in the crash dump, but not going there :) Here are the entries:
|
@jerrosenberg you not alone there! |
@jerrosenberg i stand corrected. With the debugger i have noticed some qwerks in what gets loged in the eventlog |
I think there's 2 issues here.
I think your solution to 1 is a good one. Here's my opinion on why 2:
If you really want this just for the event log write, then just write to the event log, and shut down gracefully, or at least not SO hard. :) If you're worried about the event log write failing, you could always try catch that and failfast if you can't write to the log! Then I think you would definitely meet the criteria in the msdn doc:
I think this methodology should be applied across the board wherever FailFast is currently used. But I've been wrong before.. My cents. Btw, you may enjoy this comment found here:
|
note: perhaps try catch from the code that calls topshelf and re-throw a new aggregate exception to preserve stack trace |
@johnsimons @andreasohlund proposed fix here d1c2203 the Idea is to
thoughts? |
How do u find such obscure Apis? The only thing I don't like is the public extension method on the Exception On Tuesday, June 18, 2013, Simon Cropp wrote:
Regards |
Fair point. I will make it internal. As for the voodoo... There are other ways of doing it but they involve reflection. Also we can remove the voodoo when we move to 4.5 since there is a simplified public api in 4.5 |
So what does the exception look like? On Tuesday, June 18, 2013, Simon Cropp wrote:
Regards |
Have a look at the unit test I added |
Looks good, add a comment /YT to get rid of it when we are 4.5 only On Tue, Jun 18, 2013 at 2:32 PM, Simon Cropp notifications@github.comwrote:
|
Agree, I'll merge it in today On Wednesday, June 19, 2013, Andreas Öhlund wrote:
Regards |
This issue was raised on the mailing list, see http://tech.groups.yahoo.com/group/nservicebus/message/18755
The problem is that if there is a configuration/startup exception in the NServiceBus host, the error/stacktrace of the root exception is not shown.
The code that is problematic is this (copied here for convenience):
The problem is we assume that
LogManager
has already been configured but that may not be correct because for example:What would be the state of the logger?
To address this issue I recommend we do a
Console.Out
as well.So the code would end up like:
The
Environment.FailFast
is still required because it logs to the Event Viewer as a backup in case neither of the above worked.The text was updated successfully, but these errors were encountered: