A client of mine has a long-running process that uses NAudio to record incoming audio on the default recording device for a few hours on a scheduled basis. It runs as a desktop program that is left running for days or weeks at a time.
Today he sent me this exception report:
Cannot pass a GCHandle across AppDomains.
Parameter name: handle
System.ArgumentException
at System.Runtime.InteropServices.GCHandle.InternalCheckDomain(IntPtr handle)
at System.Runtime.InteropServices.GCHandle.FromIntPtr(IntPtr value)
at NAudio.Wave.WaveIn.Callback(IntPtr waveInHandle, WaveMessage message, IntPtr userData, WaveHeader waveHeader, IntPtr reserved) in C:\Libraries\NAudio\naudio-5019c8f1c6fc\NAudio\Wave\WaveInputs\WaveIn.cs:line 132
at NAudio.Wave.WaveWindow.WndProc(Message& m) in C:\Libraries\NAudio\naudio-5019c8f1c6fc\NAudio\Wave\MmeInterop\WaveWindow.cs:line 64
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
I did some googling but couldn't find anything obvious. Is there a good patch or fix for this that doesn't involve silently catching the exception?
I'm using a home-built version of NAudio that includes a few tweaks, but nothing that should cause this error.
Related
It is a simple question that I might delete soon, but I have a problem that I don't seem to find anywhere else (at least google has not helped).
I am trying to write a plugin for a software based completely in MFC, but I refuse to use MFC myself. I thought that, in the end, I could just use the proper handles and modules to create my windows with winapi to work with MFC but it does not seem that easy. I am trying to launch a "Modal" window (that is, it blocks the parent by calling EnableWindow(parentHwnd, FALSE)). For this window I wrote a custom wndProc function:
LRESULT CALLBACK wndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam){
//Do stuff to get a HWND to the parent window
switch(msg) {
case WM_CLOSE:
EnableWindow(parentHwnd, TRUE);
//DestroyWindow(hwnd);
return DefWindowProc(hwnd, msg, wParam, lParam);
case WM_DESTROY:
EnableWindow(parentHwnd, TRUE);
//PostQuitMessage(0);
return DefWindowProc(hwnd, msg, wParam, lParam);
//... Handling other messages
When the user closes the window, I want to enable the parent and simply close my custom window. You can see that the functions DestroyWindow(hwnd) and PostQuitMessage(0) are commented, and instead I return DefWindowProc. This is because leaving the message uncommented, the whole app crashes with the following exception:
My first guess would be that there is a problem with the messages in windows. I don't know if I am forced to use the "DECLARE_MESSAGE_MAP" macro or something to handle my events in MFC's wndProc. I'm quite a beginner for windows development so, even though I found a solution for this crash, I'm not quite satisfied because I have no idea why it failed in the first place. Thank you!
First, what is a "plugin" exactly? From what I can guess it must be just some additional code, built into the main executable (otherwise you wouldn't be asking about message-maps and that "MFC's wndProc"). As for your question, maybe you don't really need to get into this. I'm just wondering if it would work just calling:
DialogBox(AfxGetInstanceHandle(), MAKEINTRESOURCE(IDD_MYDIALOG), parentHwnd, MyDlgProc);
We are building a website with UI and API, both hosted within single ASP.NET MVC project ("usual" MVC + MVC WebApi under one hood). We are using SimpleInjector (the latest version, 2.8 as of now) for dependency injection. We have single composition root class to construct containers for both UI and API parts.
Since recently (noticed a couple of weeks ago) we are receiving connection reset errors (ERR_CONNECTION_RESET) when we try accessing any API method in QA. The same code in UAT works just fine.
Locally, the same code errors out with StackOverflowException if run under IIS, but works fine under IIS Express and under IIS if we run it with debugger attached.
Our current code gives the following stack trace when we attach to iis worker process after the exception occurs:
SimpleInjector.Compiled!DynamicInstanceProducer3.GetInstance(object[] constants)
SimpleInjector.dll!SimpleInjector.CompilationHelpers.CompileInDynamicAssemblyAsClosure<System.__Canon>.AnonymousMethod__1a()
SimpleInjector.dll!SimpleInjector.InstanceProducer.GetInstance()
SimpleInjector.dll!SimpleInjector.Container.GetInstance(System.Type serviceType)
System.Web.Http.dll!System.Web.Http.Dispatcher.DefaultHttpControllerActivator.GetInstanceOrActivator(System.Net.Http.HttpRequestMessage request, System.Type controllerType, out System.Func<System.Web.Http.Controllers.IHttpController> activator)
System.Web.Http.dll!System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create(System.Net.Http.HttpRequestMessage request, System.Web.Http.Controllers.HttpControllerDescriptor controllerDescriptor, System.Type controllerType)
System.Web.Http.dll!System.Web.Http.Controllers.HttpControllerDescriptor.CreateController(System.Net.Http.HttpRequestMessage request)
System.Web.Http.dll!System.Web.Http.Dispatcher.HttpControllerDispatcher.SendAsync()
mscorlib.dll!System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start<System.Web.Http.Dispatcher.HttpControllerDispatcher.SendAsync>(ref System.Web.Http.Dispatcher.HttpControllerDispatcher.SendAsync stateMachine)
System.Web.Http.dll!System.Web.Http.Dispatcher.HttpControllerDispatcher.SendAsync(System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken)
System.Net.Http.dll!System.Net.Http.HttpMessageInvoker.SendAsync(System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken)
System.Web.Http.dll!System.Web.Http.Dispatcher.HttpRoutingDispatcher.SendAsync(System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken)
System.Web.Http.dll!System.Web.Http.HttpServer.SendAsync()
mscorlib.dll!System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start<System.Web.Http.HttpServer.SendAsync>(ref System.Web.Http.HttpServer.SendAsync stateMachine)
System.Web.Http.dll!System.Web.Http.HttpServer.SendAsync(System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken)
System.Net.Http.dll!System.Net.Http.HttpMessageInvoker.SendAsync(System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken)
System.Web.Http.WebHost.dll!System.Web.Http.WebHost.HttpControllerHandler.ProcessRequestAsyncCore()
mscorlib.dll!System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start<System.Web.Http.WebHost.HttpControllerHandler.ProcessRequestAsyncCore>(ref System.Web.Http.WebHost.HttpControllerHandler.ProcessRequestAsyncCore stateMachine)
System.Web.Http.WebHost.dll!System.Web.Http.WebHost.HttpControllerHandler.ProcessRequestAsyncCore(System.Web.HttpContextBase contextBase)
System.Web.dll!System.Web.TaskAsyncHelper.BeginTask(System.Func<System.Threading.Tasks.Task> taskFunc, System.AsyncCallback callback, object state)
System.Web.dll!System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
System.Web.dll!System.Web.HttpApplication.ExecuteStep(System.Web.HttpApplication.IExecutionStep step, ref bool completedSynchronously)
System.Web.dll!System.Web.HttpApplication.PipelineStepManager.ResumeSteps(System.Exception error)
System.Web.dll!System.Web.HttpApplication.BeginProcessRequestNotification(System.Web.HttpContext context, System.AsyncCallback cb)
System.Web.dll!System.Web.HttpRuntime.ProcessRequestNotificationPrivate(System.Web.Hosting.IIS7WorkerRequest wr, System.Web.HttpContext context)
System.Web.dll!System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(System.IntPtr rootedObjectsPointer, System.IntPtr nativeRequestContext, System.IntPtr moduleData, int flags)
System.Web.dll!System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(System.IntPtr rootedObjectsPointer, System.IntPtr nativeRequestContext, System.IntPtr moduleData, int flags)
[Native to Managed Transition]
[Managed to Native Transition]
System.Web.dll!System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(System.IntPtr rootedObjectsPointer, System.IntPtr nativeRequestContext, System.IntPtr moduleData, int flags)
System.Web.dll!System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(System.IntPtr rootedObjectsPointer, System.IntPtr nativeRequestContext, System.IntPtr moduleData, int flags)
[AppDomain Transition]
I.e., looks like nothing bad happens inside our code.
When we take some old code (one that is currently in production, for instance, and is working fine), we also have StackOverflowException, but in static constructor of our EntityFramework DB context (code first) on line
Database.SetInitializer(new MigrateDatabaseToLatestVersion<MyContextType, Configuration>());
Funny thing is that it no longer suggests to attach to the process with old code, so I cannot provide the stack trace - I will update the question, if I manage to grab it.
Note that usual MVC works normally still (while using the same Composition Root class with slight natural differences for WebApi and MVC creation modes).
I can provide further code snippets, if it is reasonable, but the project is quite big, so I am not sure small snippets will help here.
Any ideas what this might be? Can it be because of the number of dependencies?
UPDATE: The issue does not appear after in one of the services which depends on four other services I removed the dependencies from the constructor, injected the container there, and resolved the dependencies manually in the constructor. I.e., it was:
public MyDependentService(IDependency1 dependency1, IDependency2 dependency2, IDependency3 dependency3, IDependency4 dependency4)
{
this.dependency1 = dependency1;
this.dependency2 = dependency2;
this.dependency3 = dependency3;
this.dependency4 = dependency4;
}
and it became
public MyDependentService(Container container)
{
this.dependency1 = container.GetInstance<IDependency1>();
this.dependency2 = container.GetInstance<IDependency2>();
this.dependency3 = container.GetInstance<IDependency3>();
this.dependency4 = container.GetInstance<IDependency4>();
}
So now everything works, but of course this is not the right way to deal with dependencies. This is actually not IoC anymore. What's going on?
I am running IIS 8 and Windows Server 2012. I have installed Web Deploy and when I try to select a user to give publishing permissions to, I immediately crash without any error dialogs. When I go into the Event Viewer, I am able to see the following error:
IISMANAGER_CRASH
IIS Manager terminated unexpectedly.
Exception:System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.OverflowException: Arithmetic operation resulted in an overflow.
at Microsoft.Web.Deployment.UI.ObjectPickerWrapper.ShowObjectPicker(IntPtr parentHandle, Boolean usersOnly)
at Microsoft.Web.Deployment.UI.SelectExistingUserForm.OnWindowsBrowseButtonClick(Object sender, EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr dwComponentID, Int32 reason, Int32 pvLoopData)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Form.ShowDialog(IWin32Window owner)
at Microsoft.Web.Management.Host.UserInterface.ManagementUIService.ShowDialogInternal(Form form, IWin32Window parent)
at Microsoft.Web.Management.Host.UserInterface.ManagementUIService.Microsoft.Web.Management.Client.Win32.IManagementUIService.ShowDialog(DialogForm form)
at Microsoft.Web.Deployment.UI.SetupPublishingDialog.SelectUserButton_Click(Object sender, EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr dwComponentID, Int32 reason, Int32 pvLoopData)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Form.ShowDialog(IWin32Window owner)
at Microsoft.Web.Management.Host.UserInterface.ManagementUIService.ShowDialogInternal(Form form, IWin32Window parent)
at Microsoft.Web.Management.Host.UserInterface.ManagementUIService.Microsoft.Web.Management.Client.Win32.IManagementUIService.ShowDialog(DialogForm form)
at Microsoft.Web.Deployment.UI.PackagingModule.SetupPublishing(HierarchyInfo info)
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
at System.Windows.Forms.ToolStripItemClickedEventHandler.Invoke(Object sender, ToolStripItemClickedEventArgs e)
at System.Windows.Forms.ToolStripDropDown.OnItemClicked(ToolStripItemClickedEventArgs e)
at System.Windows.Forms.ToolStrip.HandleItemClick(ToolStripItem dismissingItem)
at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
at System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ToolStrip.WndProc(Message& m)
at System.Windows.Forms.ToolStripDropDown.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr dwComponentID, Int32 reason, Int32 pvLoopData)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
at Microsoft.Web.Management.Host.Shell.ShellApplication.Execute(Boolean localDevelopmentMode, Boolean resetPreferences, Boolean resetPreferencesNoLaunch)
Process:InetMgr
I thought Microsoft had a complete process in place eliminating such easy to find bugs. What gives?
I encountered this exact issue when attempting to configure web deploy publishing; IIS Manager would crash instantly when clicking the Select... button when attempting to select a user to give publishing permissions.
To work around it, I manually entered the username into the text field, in the format COMPUTERNAME\Username.
For me
adding required User with the "IIS Manager Permissions" GUI for the
site
simply choose them from the drop down (instead of choosing the Ellipse to search for /
select a user)
Avoided the issue entirely and all seems to have worked fine
This is a bug that hasn't been fixed and apparently is of low priority. The only fix for me that works is to use an account with administrator privileges and ignore the dialog. A standard user account may work, but you have to find out what permissions needs to be applied. Frankly, Microsoft's security scheme is too complex to setup, which is why many sysadmins just turn it off or give full privileges to get around authentication denied problems. Web Deploy is a big rats nest of inter-operating components all of which have to have their permissions carefully tweaked. If someone has the time, which I don't have much of, download process explorer and setup a filter to watch for access denial errors and apply the appropriate permissions to the process or user.
Microsoft software has always been bad, but it's been getting progressively worse. If it were a company run by two guys operating out of their basement, this and other bugs would be perfectly understandable. But this is a multi-billion dollar corporation and it can't get basic software that's critical for its own survival right.
Microsoft is fighting too many battles and it's losing all of them. It's losing in the mobile market, the web server market and it will eventually lose the enterprise and the desktop market, since applications are moving away from the desktop. If there's no way of simply deploying web applications, it can just forget about the cloud market.
If you're a Microsoft only developer, you should start seriously looking at a career change. Don't base your livelihood on a sinking ship.
I have subclassed a window using SetWindowSubclass(), and my message handler is successfully called, but when I call DefWindowProc() to pass the messages on for their original processing, no messages ever get through!
We are writing an extension to Marmalade (a kit for cross-platform mobile development). It allows for native extensions for specific platforms, and we're writing one for the Windows desktop build. We don't have direct access to the message loop, but can subclass to handle messages ourselves, however we don't seem to be able to pass the messages back to Marmalade for normal processing.
For example, even doing nothing in the callback but calling DefWindowProc() still doesn't work:
// Initialization:
const UINT_PTR gSubClassId = NULL;
DWORD_PTR subClassCBData = NULL;
SetWindowSubclass(gMainWindow, CadUtil_WindowCB, gSubClassId, subClassCBData);
...
// Message processing callback.
static LRESULT CALLBACK CadUtil_WindowCB(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam, UINT_PTR uIdSubclass, DWORD_PTR dwRefData)
{
// Messages are correctly diverted here, but DefWindowProc() below isn't passing them on.
return DefWindowProc(hWnd, message, wParam, lParam);
}
Any idea how this can happen?
Thanks,
Rob.
I think the problem with your code example is that you should call DefSubclassProc instead of DefWindowProc when subclassing a window.
I still don't know why subclassing didn't work, but I was able to work around it by using hooks instead. So instead of using SetWindowSubclass() to capture messages and DefWindowProc() to pass them through, I now use SetWindowsHookEx() with WH_CALLWNDPROC and WH_GETMESSAGE to capture messages, and call CallNextHookEx() in the hook to pass messages through. This works where subclassing wouldn't.
While debugging the project Visual studio showing some error.And when I am trying to add a table in database file(.mdf extension) then the VisualStudio automatically restarts.
Error list-->
System.IO.FileNotFoundException: Error reading the C:\Windows\TEMP\ directory.
at System.IO.FileSystemWatcher.StartRaisingEvents()
at System.IO.FileSystemWatcher.set_EnableRaisingEvents(Boolean value)
at Microsoft.IisExpress.SysTray.TrayAppHiddenForm.TrayAppHiddenForm_Load(Object sender, EventArgs e)
at System.Windows.Forms.Form.OnLoad(EventArgs e)
at System.Windows.Forms.Form.OnCreateControl()
at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
at System.Windows.Forms.Control.CreateControl()
at System.Windows.Forms.Control.WmShowWindow(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
at System.Windows.Forms.ContainerControl.WndProc(Message& m)
at System.Windows.Forms.Form.WmShowWindow(Message& m)
at System.Windows.Forms.Form.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
Please Help me to solve this error.
Hey It happen also with me , issue solved when I go to direct in directory C:\Windows\TEMP and system ask me access to this folder and I click yes for that so that current User has rights on that folder and error gone. This is access rights issue after my windows UPDATE
This blog post definitely solved the problem that we were facing (This will describe the problem we were facing). - http://devatheart.azurewebsites.net/2011/04/18/troubleshooting-xmlserializer-failure/
We had this piece of code
System.Diagnostics.Process.Start(RetrievedURL);
which was generating IE processes (Since IE was the default browser on the webserver) in the background on the button click and opening webpage.
Not a smart thing to have but we removed that code and it has definitely stopped the IE processes in the background.
How it is linked to XML Serialization Failure is explained in the above post. Thanks for the research and this blog post Slobodan Stipic, a.k.a. Slobo.
Hope this solution helps.