I have a WPF audio application.
Occasionally (and even in the debugger) I'm seeing a NullReferenceException
which carries no stack trace information with it.
How can one start debugging such an issue?
Some background:
I'm P/Invoking functions in WinMM.dll
which involves registering a callback when calling waveOutOpen
[DllImport("winmm.dll")]
public static extern MmResult waveOutOpen(out IntPtr phwo, IntPtr uDeviceID, WaveFmt pwfx, WaveCallbk dwCallback, IntPtr dwInstance, int fdwOpen);
This has proved difficult to get stable, especially at the point where I call waveOutClose
, and immediately call waveOutOpen
again (usually to change the output format).
I suspect that the problem may be related to the calls I've been describing above (although on so little knowlege, I could be completely off-target).
Reproducing the problem is currently proving elusive, although I can supply a build to a user who is fairly consistently seeing this problem. I might try to speed up the operations that are causing the problem to the point where reproducing the problem in the debugger is more of a certainty.
With regards to the debugger, I haven't tinkered with any of the settings (including Enable unmanaged code debugging
) or any of the Debug -> Exceptions...
settings. To be honest,开发者_C百科 I'm fairly clueless about what's on offer here, so any hints are welcome.
How might an exception not have a stack trace? Have you seen this before? Help!
The most helpful thing you can do in the debugger is instruct it to break on a first-chance exception (Debug -> Exceptions):
This will cause a break into the debugger at the exact point a NullReferenceException
is thrown, which is pretty much the best you can ever hope for while debugging.
精彩评论