I have a C# web service that is calling COM objects to access a FileNet imaging system. The service is occasionally encountering the following error when making a call to the FileNet COM objects:
System.Runtime.InteropServices.COMException (0x80040005): Need to run the object to perform this operation (Exception from HRESULT: 0x80040005 (OLE_E_NOTRUNNING))
Any idea on what this means, or how to troubleshoot it? I could find almost nothing when searching with Google, and my experience with COM is very limited. Thanks.
Unfortunately, that HRESULT is the "Something Went Wrong" error code. I would suggest:
Check the system and application event logs to see if there are any better error messages being logged
Check any application specific error logs for your COM component
If neither of those shed any more light on what is going wrong, you may want to consider adding your COM assembly to a Component Services package. This should let you shut it down and restart it much more easily without having to reboot the system.
Depending on the OS (This is from Windows 7, but most are similar):
Start component services (under Administrative tools, usually)
Drill down to Component Services, Computers, My Computer, COM+ Applications.
Right click to add a new application.
Choose to create an empty application. This will let you pick which COM components you want to run in here.
Give the application a name
If you don't know much about your COM component, I would recommend choosing a Server application to start. This will start it out-of-process for the caller. If this doesn't work (e.g. calls fail and such), remove this application and try again as a library application.
Pick the credentials for the service. Network Service is probably the safest choice (e.g. fewest permissions), but I have no idea what your requirements are. You may need to provide a domain account or LocalSystem if it is accessing hardware or other such things.
Finish out the wizard (you may need to revisit these if you need more control).
Drill into your new Application and find the Components folder.
Right click and choose New Component
If the COM controls are already registered, choose Import components. If not, choose Install Components
Now select the components you care about. Note that it is fairly important to get all the inter-related components into the same application. Otherwise, older COM assemblies are unlikely to work correctly
Finish out the wizard. If you go back to the COM+ Application level of the tree view you should see your new application, with a non-animated icon.
There shouldn't be any changes necessary to the calling code. Make a request to your service and go back to the manager... you should see the icon animate once the COM+ Application starts up. You should also be able to re-start it from here, if you desire.
There are a lot of configuration options around spin-down time and pooling, so that may help you to if you find that the COM DLL only gives issues after a certain period of time, for example.
If the problem is truly intermittent, and sometimes happens on one machine, and sometimes doesn't - you could write your code to trap the error, and have it try again.
If there are machines it never works on, it may be due to some other issue, such as UAC, or the component not being properly installed.
Related
I have a certain .net application that occasionally crashes with one of the following windows errors:
[application name] has encountered a problem and needs to close. We are sorry for the inconvenience.
or
[application name] has stopped working
I want to monitor this app from another .net process, prevent showing the default windows error report dialog, and do my own error processing.
Is there a way I can detect that the other app has crashed?
And can I prevent or hide the default error dialog?
Some background information: I do have the code for the crashing app, and I can change it if necessary. However the crash is caused by a third party unmanaged assembly, which overwrites some memory and leaves the app in an unrecoverable state. A simply try-catch block is not enough to prevent the crash. This is why I want to monitor and handle the error from a separate process.
If the app writes to the windows event log, your other program could check there for errors
Can AppDomain.UnhandledException help?
The dialog box is a function of Windows Error Reporting (WER).
Is there a way I can detect that the other app has crashed?
There are plenty of options, from a service that requires some kind of heartbeat message from the process, to enabling catching of corrupted state exceptions, to enabling a corporate WER server. (link below)
[C]an I prevent or hide the default error dialog?
The WER configuration documentation has information about excluding a process from the automatic dialog.
Specifically the registry key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\
Windows Error Reporting\ExcludedApplications\[Application Name]
(HKCU has a similar key)
Unfortunately, if it's an access violation, you're pretty well hosed. By the time that the exception has made it to WER the entire stack is blown, and the memory is already corrupt.
Disabling the built in error reporting for your application, will also prevent the automated creation of minidumps, which may be helpful, if not in solving the direct issue, providing ammunition for use convincing the vendor to fix their dll.
If the vendor is unwilling or unable to fix the problem, you could copy the way Explorer handles shell extensions, and host the component in a separate process. That way, when it crashes, it only trashes the memory of the other process. You'd have to write a wrapper to allow you to communicate with it.
I have just created a windows service. Since there isn't really a way to debug services(that I know of)I created the majority of the application as a desktop console application that accessed the libraries I created that it uses. When doing this everything worked great. So once I created the service to do the same job the console was doing(all the console did was open and automatically start it's job) and installed it with sc.exe and started it up, it doesn't seem to be doing it's job which is basically listening for connections.
Is there anything else I have to do for my service to be able to access these libraries? Do I have to somehow register them so they will work together? This is a standard windows service created in C#.
I am so glad you got it working. I know i have seen many have this problem.... And to think my own question about it got down voted.
But anyways these are called Loader Service(by Microsoft) not Windows Service. They are the same thing except the former has the ability to interact with GUI.
I know its a couple of months later this answer but...Your problem is not the library... its the process itself. Use this Thread, I was able to create my own solution for this problem since many had the problem but noone gave the solution to it directly. My Solution - C# Windows Service Creates Process but doesn't executes it
We are currently trying to incorporate Lync communication (Lync SDK 2010) into our application and we have run into an issue with the VideoWindows (CaptureVideoWindow, RenderVideoWindow) of the AVModality's VideoChannel: They are always null, even after successfully calling BeginStart. The connection is definitely established. We can talk. Our own video is shown in a remote Lync client. AVModalityState is Connected. VideoChannelState goes from Connecting to Receive to Send.
It does not matter when and how we try to access them: Directly after BeginStart, in the AsyncCallback of BeginStart, in response to various state changes or in response to an external trigger (user click event); in the main/UI thread or in an event/callback thread. The two video windows are always null.
In the example application "%PROGRAMFILES%\Microsoft Lync\SDK\Samples\AudioVideoConversation", everything works as intended: As soon as BeginStart has finished, we can access the non-null video windows. In our little stand-alone prototype project, it works, too. But in our real application, it does not.
We have double checked everything and we have really run out of ideas of what might cause this problem.
Any ideas, any hints? Anything that we should be aware of?
(Link to corresponding MSDN forum thread)
Update (4th July 2012, 15:46 CET):
When we take a look at the members of the VideoChannel we find that internally a COMException occured in "Microsoft.Office.Uc": Error loading DLL, HRESULT: 0x80029C4A (TYPE_E_CANTLOADLIBRARY). More details in the attached screenshot.
We did some research on this error, but found nothing that worked for us. Any ideas what causes the Exception?
Update (9th July 2012, 16:43 CET):
We did some further testing...
Our software consists of one main application and many plugin-like "apps" loaded via MEF. We created a minimal test app that makes a video call: The video windows did not work (as expected). But when we took the identical code and created a separate solution outside of our architecture, then it did work. So, it was an issue with the environment, not the code.
At first, we suspected MEF might be the problem. So, we hacked the lync code into our main application - circumventing the whole app architecture. Still not working.
Then we sliced off our whole system, bit by bit, until we finally reached a point where it did work. After following wrong tracks several times, we finally found the culprit... Quartz.NET!
For some strange reason the mere presence of an assembly reference to the Quartz.dll v.1.0.3.3, even without a single line of Quartz code, causes the video windows to not work. Unbelievable, but it's 100% reproducible: If we take the previously mentioned test solution and do nothing but add the reference, it stops working.
Any idea how such a thing is possible?
We solved it! Kind of. A reference to a Quartz.NET DLL somehow caused the issue. More details in the updated question.
For now, we have removed the component that used Quartz. We currently do not need it.
But I'm still interested in further input how a mere reference can cause such an issue.
I'm developing a commercial Windows 7 desktop application (somewhat shrink wrap, but not quite). The application has both Windows Service and a WPF User Interface components. In the event that our application fails at a customer site we want to be able to capture information about the runtime environmnent, including a crash dump of our processes to a dump location. That information could then be forwared to our support personnel upon request for further investigation. We also want to turn off any Windows Error Reporting and Send To Microsoft dialogs that might popup as a result of the failure.
The important thing is that we only want this to affect our application processes. We don't want to affect some global setting that will change the way all other applications on the customers desktop report fatal errors.
I'm looking for some suggestions and best practices for doing this sort of thing in a shrink wrap application.
The best way I know how to do this is by subscribing to the AppDomain.CurrentDomain.UnhandledException event. There you will be able to use the Win32 API function MiniDumpWriteDump to create your own minidump file. Check out this blog post to see a good example. Also, there is the ClrDump library.
Before you exit from your UnhandledException handler, call Environment.Exit() and you shouldn't see any more Windows error dialogs.
I have not actually used these minidump libraries myself yet, but I will soon. Hopefully this answer will at least give you a few keywords that you can plug into Google.
i wish to load my C# application after windows user login and before windows desktop appears. currently i added my application startup path to registry run key. it loads my application correctly but windows windows desktop appears[2 sec] then my application runs
Note:
My application creates seperate desktop using winapi, while my application running it hides the desktop temporarily.
This really isn't possible to do. Windows works pretty hard to get the desktop up and explorer responsive as soon after the user logs in. This is what is most important to the user.
Your goals may be noble, but they are at odds with what users want. So in general, they are at odds with how Windows works (especially Win-7).
If you have software that needs to run early that doesn't need to interact with the user, then a service is they way to go. It is important to note that in Vista and later Windows systems, there is no way for a service to interact with the user - e.g. they cannot have their own graphical user interface. Services with UI are inherently not secure.
One way to partition your software is to put some things in a service, and have a think UI layer on top of it. COM and Local RPC are good choices for communication between your service and your UI layer.
Note that you will need to do work here to prevent your components from slowing down boot. Poorly behaving applications are one of the biggest problems in the boot path. You can study this using the Windows Performance Toolkit
It is kinda possible I think, but you are really in for a lot of extra work. What you could do is replace the Windows Shell with your own code, but at that point you become solely responsible for the UI that the user interacts with.
If your code isn't 'just right', you may end up with an unusable Windows install, and I'm not sure your users are going to appreciate that much.
Also note that there may be features that you normally intuitively expect to be available on a Windows machine that are part of the shell which you will not have access to anymore. For details, try http://en.wikipedia.org/wiki/Windows_shell_replacement as a starting point.
Addendum:
I have only the vaguest knowledge myself about what is actually involved technically to make this happen, but http://dustyant.com/articles/deeshell/ seems to be a decent explanation of the basics. Again tho... here be dragons make sure you do this in a VM or something so that you don't end up stuffing your main Windows install.
Just briefly what 'Shell Replacement' means: after you log in, windows starts an application called 'explorer' (not sure if this still holds for Vista / Win 7... I have a vague recollection it got a little more involved recently), which basically draws the desktop, the taskbar, etc. ... it is possible to tell Windows to start a different application instead of the default graphical shell. At that point you are in control of the main UI of Windows... which means that you are responsible for everything that Windows normally does in the shell ... gives you a lot of control and flexibility, and possibly lots of headaches.