Got an issue where I am a COM type in c# using
this.rtwbType = Type.GetTypeFromProgID(progId, true);
this.rtwb = Activator.CreateInstance(this.rtwbType);
I am then doing some stuff, and when I am done I call exit on the rtwb - so it can close down, and then calling:
Marshal.ReleaseComObject(this.rtwb);
In 2008 R2 this is fine and dandy - but the instance we take to 2012 an exception is thrown here.
System.Runtime.InteropServices.COMException (0x800706BA): The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)
like I say works fine elsewhere.
Any pointers?
The following code reproduces this error (at least under Windows 8.1):
var type = Type.GetTypeFromProgID("InternetExplorer.Application", true);
dynamic ie = Activator.CreateInstance(type);
ie.Quit(); // this disconnects the COM proxy from the out-of-proc IE object
Marshal.ReleaseComObject(ie); // throws
Apparently, the implementation of ReleaseComObject is doing something more than calling IUnknown::Release, when it deals with a COM proxy object. My guess is, it may be calling IRemUnknown::RemRelease, which returns HRESULT with an error, so ReleaseComObject throws, because the out-of-proc object has been already disconnected and destroyed with ie.Quit().
Presumably, this behavior was introduced in Windows Server 2012.
The best thing you could probably do is to ignore this specific error:
try
{
Marshal.ReleaseComObject(ie);
}
catch (COMException ex)
{
// I'm getting 0x80010108, rather than 0x800706BA
// The object invoked has disconnected from its clients. (Exception from HRESULT: 0x80010108 (RPC_E_DISCONNECTED)
if ((uint)ex.ErrorCode != 0x80010108)
throw;
}
Updated: this is the expected behavior for an API like Quit, it doesn't violate any COM rules. The goal of Quit is to provide an API for explicit shutdown. I believe it uses CoDisconnectObject internally, as a part of the shutdown process. This disconnects all external proxy references, so the server knows it can shut down safely.
The fact that ReleaseComObject is still trying to do some stuff after that (like, most likely, calling IUnknown::QueryInterface on the disconnected proxy) is not a fault of the COM server.
I'm assuming that rtwb is an InternetExplorer.Application, as Noseratio's test seems to replicate the issue rather well.
It seems Internet Explorer's Quit() method is not really safe to call outside the application's context, e.g. through out-of-process automation. It violates the rules of COM server applications.
For instance, Office applications keep running while there are external references, even after Quit(), so this is really a bit unexpected.
For safety, you can let the reference go when quitting, using the OnQuit event:
using System;
using System.Threading;
using System.Runtime.InteropServices;
public class TestIE
{
public static void Main()
{
Console.WriteLine("Creating application");
dynamic app = Activator.CreateInstance(Type.GetTypeFromProgID("InternetExplorer.Application"));
Console.WriteLine("Created application");
app.Visible = true;
app.OnQuit += new Action(() => {
Console.WriteLine("Entered OnQuit");
Marshal.ReleaseComObject(app);
app = null;
Console.WriteLine("Leaving OnQuit");
});
Console.WriteLine("Sleeping");
Thread.Sleep(5000); // enough time to see if iexplore.exe is running
Console.WriteLine("Slept");
Console.WriteLine("Quitting");
app.Quit();
Console.WriteLine("Quit");
Console.WriteLine("Sleeping");
Thread.Sleep(5000); // enough time to see if iexplore.exe is running
Console.WriteLine("Slept");
Console.WriteLine(app == null);
}
}
If you really need to use ReleaseComObject, discard any exceptions it might throw. I'm not sure if you should discard only COMException, try it out during development.
Related
I am working on an Excel Addin using C#, Visual Studio 2012. I am trying to get the instance of Excel's Application object so as to keep track of the currently active workbook and worksheet (ActiveWorkbook, ActiveWorksheet).
I see that most other related questions on SO have replies suggesting to use the following:
(Excel.Application)Marshal.GetActiveObject("Excel.Application");
I have also tried using this:
(Excel.Application)Globals.ThisAddIn.Application;
In both of the cases I get NullReferenceException. After looking at the workaround suggested here: http://support.microsoft.com/kb/316125/en-us, I tried the following to test both methods.
public CurrentSpreadSheet()
{
try
{
this.CurrentApplication = (Excel.Application)Globals.ThisAddIn.Application;
}
catch (NullReferenceException)
{
MessageBox.Show("Excel application object not registered. Trying plan B..");
//Getting Excel's application object instance
int iSection = 0, iTries = 0;
tryAgain:
try
{
iSection = 1; //Attempting GetActiveObject
this.CurrentApplication = (Excel.Application)Marshal.GetActiveObject("Excel.Application");
iSection = 0; //GetActiveObject succeeded so resume or go for normal error handling if needed
this.CurrentApplication.Visible = true;
}
catch (Exception err)
{
System.Console.WriteLine("Visual C# .NET Error Attaching to Running Instance of Office Application .. yet.");
if (iSection == 1)
{
//GetObject may have failed because the
//Shell function is asynchronous; enough time has not elapsed
//for GetObject to find the running Office application. Wait
//1/2 seconds and retry the GetObject. If we try 20 times
//and GetObject still fails, we assume some other reason
//for GetObject failing and exit the procedure.
iTries++;
if (iTries < 20)
{
System.Threading.Thread.Sleep(500); // Wait 1/2 seconds.
goto tryAgain; //resume code at the GetObject line
}
else
{
MessageBox.Show("GetObject still failing. Process ended.");
}
}
else
{
//iSection == 0 so normal error handling
MessageBox.Show(err.Message);
}
}
}
}
The output is:
Excel application object not registered. Trying plan B..
GetObject still failing. Process ended.
In some rare cases "plan B" does work; I don't see the second message box.
CurrentSpreadSheet is a singleton and I intend to update it during startup from the provided class ThisAddIn.
In ThisAddIn I have something like:
private CurrentSpreadSheet css = CurrentSpreadSheet.Instance;
private void ThisAddIn_Startup(object sender, System.EventArgs e)
{
///...Some code
css.updateCurrentSpreadSheet();
}
Is there a better way of getting the Application object? If this is not possible right during the startup, is there a better way by which I can keep track of currently active worksheet/workbook right from the startup of excel/my add-in? Currently I am depending on the Application object (e.g. (Excel.Workbook)this.CurrentApplication.ActiveWorkbook;) and some event handlers to keep track of the current workbook and worksheet.
I tried using ExcelDNA:
this.CurrentApplication = (Excel.Application)ExcelDna.Integration.ExcelDnaUtil.Application;
This works some of the times but mostly gives this error:
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> ExcelDna.Integration.XlCallException: Exception of type 'ExcelDna.Integration.XlCallException' was thrown.
Keep in mind that an Office add-in runs inside the Office process. So you never want to find an external process. The boilerplate ThisAddIn class that you get when you use a Office project template hands you the Application object you are looking for on a silver platter, use its Application property. The first time you can get to it is in the Startup event, make sure you don't try it earlier. So don't do anything drastic in your constructor and don't initialize class members with initialization expressions, wait until Startup fires.
The relevant MSDN page is here, "Accessing the Object Model of the Host Application" section.
You might take a closer look at http://netoffice.codeplex.com/ There you can find more stuff about Add-In's for Word/Excel/Powerpoint.
Also keep in mind the GuidAttribute when you load your Add-In, because depending on your Office version it won't work anymore and also, check to kept your project whether 32/64-bit, best is Any CPU. Also, keep in mind to register your Add-In into the registry for further usage. If you want further information, don't hesitate to write me a mail.
http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.guidattribute.aspx
While an app tries to connect to database server and retrieve some data, it sometimes raise an exception and it seems like it leaves dead threads when expcetion raised even when it's handled. So there are about 300 threads that getting service down.
Here is code invoked periodically on timer:
Parallel.ForEach(dbs, pair =>
{
db l = pair.Value;
if (String.IsNullOrEmpty(l.city))
l.city = l.configCity;
using (OracleConnection conn = new OracleConnection(l.connString))
{
try
{
conn.Open();
}
catch (Exception exc)
{
Console.WriteLine(String.Format("({0}, {1}): {2}{3}", l.connAlias, l.lid, exc.Message, Environment.NewLine));
}
try
{
if ((conn != null) && (conn.State == ConnectionState.Open))
{
// This method just call stored procedure and then set received data to 'l' object
if (!DbConnection.SetBadicData(conn, ref l))
{
Console.WriteLine(String.Format("Couldn't refresh basic data on ({0}, {1})", l.connAlias, l.id));
}
// This method also just call procedure and set received data to object
if (!DbConnection.SetExtendedData(conn, ref l))
{
Console.WriteLine(String.Format("Couldn't refresh advanced data on ({0}, {1})", l.connAlias, l.lid));
}
}
}
catch (Exception exc)
{
Console.WriteLine(String.Format("({0}, {1}): {2}{3}", l.connAlias, l.lid, exc.Message, Environment.NewLine));
}
}
});
Exceptions are:
Attempted to read or write protected memory. This is often an
indication that other memory is corrupt
Internal exception in Oracle client
SEHException - External component has thrown an exception
Component that used to connect to database is devArt dotConnect for Oracle.
How can I manage it guys? Does BeginConnect and then forced breaking by EndConnect will help?
Get a fixed library :-)
But seriously. If you have a third party library that you have to use, cannot change it and which is buggy, the only way I see is to run it in a separate AppDomain. Communication between domains is more difficult than just calling a method but still relatively easy. You can for example use a WCF service (with named pipe) to communicate.
Once you have your code handling nasty library in a separate AppDomain, you can recycle (destroy and recreate) that domain periodically or under other conditions. That will kill off all hanging threads, unreleased objects etc.
It is a workaround type of solution but it should give you at least a way out of this.
My application is working as a client application for a bank server. The application is sending a request and getting a response from the bank. This application is normally working fine, but sometimes
The I/O operation has been aborted because of either a thread exit or
an application request
error with error code as 995 comes through.
public void OnDataReceived(IAsyncResult asyn)
{
BLCommonFunctions.WriteLogger(0, "In :- OnDataReceived",
ref swReceivedLogWriter, strLogPath, 0);
try
{
SocketPacket theSockId = (SocketPacket)asyn.AsyncState;
int iRx = theSockId.thisSocket.EndReceive(asyn); //Here error is coming
string strHEX = BLCommonFunctions.ByteArrToHex(theSockId.dataBuffer);
}
}
Once this error starts to come for all transactions after that same error begin to appear, so
please help me to sort out this problem. If possible then with some sample code
Regards,
Ashish Khandelwal
995 is an error reported by the IO Completion Port. The error comes since you try to continue read from the socket when it has most likely been closed.
Receiving 0 bytes from EndRecieve means that the socket has been closed, as does most exceptions that EndRecieve will throw.
You need to start dealing with those situations.
Never ever ignore exceptions, they are thrown for a reason.
Update
There is nothing that says that the server does anything wrong. A connection can be lost for a lot of reasons such as idle connection being closed by a switch/router/firewall, shaky network, bad cables etc.
What I'm saying is that you MUST handle disconnections. The proper way of doing so is to dispose the socket and try to connect a new one at certain intervals.
As for the receive callback a more proper way of handling it is something like this (semi pseudo code):
public void OnDataReceived(IAsyncResult asyn)
{
BLCommonFunctions.WriteLogger(0, "In :- OnDataReceived", ref swReceivedLogWriter, strLogPath, 0);
try
{
SocketPacket client = (SocketPacket)asyn.AsyncState;
int bytesReceived = client.thisSocket.EndReceive(asyn); //Here error is coming
if (bytesReceived == 0)
{
HandleDisconnect(client);
return;
}
}
catch (Exception err)
{
HandleDisconnect(client);
}
try
{
string strHEX = BLCommonFunctions.ByteArrToHex(theSockId.dataBuffer);
//do your handling here
}
catch (Exception err)
{
// Your logic threw an exception. handle it accordinhly
}
try
{
client.thisSocket.BeginRecieve(.. all parameters ..);
}
catch (Exception err)
{
HandleDisconnect(client);
}
}
the reason to why I'm using three catch blocks is simply because the logic for the middle one is different from the other two. Exceptions from BeginReceive/EndReceive usually indicates socket disconnection while exceptions from your logic should not stop the socket receiving.
In my case, the request was getting timed out. So all you need to do is to increase the time out while creating the HttpClient.
HttpClient client = new HttpClient();
client.Timeout = TimeSpan.FromMinutes(5);
I had the same issue with RS232 communication. The reason, is that your program executes much faster than the comport (or slow serial communication).
To fix it, I had to check if the IAsyncResult.IsCompleted==true. If not completed, then IAsyncResult.AsyncWaitHandle.WaitOne()
Like this :
Stream s = this.GetStream();
IAsyncResult ar = s.BeginWrite(data, 0, data.Length, SendAsync, state);
if (!ar.IsCompleted)
ar.AsyncWaitHandle.WaitOne();
Most of the time, ar.IsCompleted will be true.
I had this problem. I think that it was caused by the socket getting opened and no data arriving within a short time after the open. I was reading from a serial to ethernet box called a Devicemaster. I changed the Devicemaster port setting from "connect always" to "connect on data" and the problem disappeared. I have great respect for Hans Passant but I do not agree that this is an error code that you can easily solve by scrutinizing code.
In my case the issue was caused by the fact that starting from .NET 5 or 6 you must either call async methods for async stream, or sync methods for sync strem.
So that if I called FlushAsync I must have get context using GetContextAsync
What I do when it happens is Disable the COM port into the Device Manager and Enable it again.
It stop the communications with another program or thread and become free for you.
I hope this works for you. Regards.
I ran into this error while using Entity Framework Core with Azure Sql Server running in Debug mode in Visual Studio. I figured out that it is an exception, but not a problem. EF is written to handle this exception gracefully and complete the work. I had VS set to break on all exceptions, so it did. Once I unchecked the check box in VS to not break on this exception, my C# code, calling EF, using Azure Sql worked every time.
I've built a program in C# Windows Forms, now on the first load up it tries to create scheduled tasks. If it raises an exception and it's in main computer then this is the first time the softwere loads (you can intall this program on many computers but one computer is the main with the scheduled tasks).
I've tried this program on many computers and it worked perfectly (XP-SP1/2, Vista-SP1/2, Win7), now when I try to install it on a limited user (on Win XP Pro SP2) it tries to create the scheduled tasks. I get an Argument Null Reference and when I enter the admin user, it installs the scheduled task on the admin user and won't run if the limited user is logged in (which is 99.9% of the time) .Why do I get this exception? I've looked for hours on the code searching for the reason of this exception but I can't find it!
Thanks a lot!
Amit
MainOrSec = true;
User and Pass are public variables whice return from FirstTimeUp.
private bool CreateNoExit()
{
try
{
RegistryKey key = Registry.CurrentUser;
key = key.OpenSubKey("Crm");
MainOrSec = Convert.ToBoolean(AESIMP.Decrypt((string)key.GetValue(AESIMP.Encrypt("MorS"))));
}
catch (ArgumentNullException)
{
MainOrSec = true;
}
if (MainOrSec)
{
ScheduledTasks sc = new ScheduledTasks();
Task task;
try
{
task = sc.CreateTask("NoExit");
FirstTimeUp f = new FirstTimeUp(this);
f.ShowDialog();
}
catch (ArgumentException)
{
return false;
}
if (!CreatT)
return false;
task.ApplicationName = #"C:\Program Files\Triffon\Crm Setup
2.0.0002\noexit.exe";
task.Comment = "Check For no exit on the database.";
task.SetAccountInformation(User, Pass);
task.IdleWaitMinutes = 10;
task.Triggers.Add(new DailyTrigger(5, 0));
try
{
task.Save();
task.Close();
sc.Dispose();
}
catch (COMException ex)
{
MessageBox.Show(ex.Message);
return false;
}
return true;
}
return false;
}
OK, so if you get an exception, the best thing to do is to run your program under Visual Studio's debugger so you can see exactly where the exception is called. Here, Ctrl-Alt-E is your friend: turn on the checkbox in the "Thrown" column next to "Common Language Runtime Exceptions" and you'll break to the debugger no matter what.
If you are testing your application on a user's computer without Visual Studio then you have some other options. One (if you're using Pro and above) is to run the Remote Debugger on the remote PC. Then you can attach to the running program and see the exception.
If you don't have Pro, or can't easily use the remote debugger, then it is definitely worth using a decent logging framework like log4net to make sure that all exceptions are caught, trapped, and written to a log file. Frankly no production application should be released until this is done.
When you've done this, take a careful look at the exception trace to see where the problem is caused. I'd be willing to bet that that ScheduledTasks class is throwing an exception somewhere that you're not expecting.
Finally, you'll be getting downvotes because the culture here is "we'll help if you let us know everything we need to know to help." There's been a couple of requests in the comments for the full stack trace, which hasn't appeared, so people here will consider that rude, I'm afraid.
It's hard to figure this out without a stack trace, but there is a suspicious line of code.
According to MSDN RegistryKey.GetValue() returns:
The value associated with name, or a
null reference (Nothing in Visual
Basic) if name is not found.
Here you pass the result of that function directly to another function:
MainOrSec = Convert.ToBoolean(AESIMP.Decrypt((string)key.GetValue(AESIMP.Encrypt("MorS"))));
Try to call it in a few steps instead, checking for null where needed:
string s = key.GetValue(AESIMP.Encrypt("MorS")) as string;
if(!string.IsNullOrEmpty(s))
MainOrSec = Convert.ToBoolean(AESIMP.Decrypt(s));
else
MainOrSec = true;
I have the following problem, basically i have a WCF service which operates fine in small tests. However when i attempt a batch/load test i get an InvalidOperationException with the message when the open() method is called on the proxy class:
"The communication object, System.ServiceModel.Channels.ServiceChannel, cannot be modified while it is in the Opened state."
I have searched google, but cannot find anyone else really quoting this exception message.
I guess some further info on the service may be necessary for a diagnosis - when the service receives data through one of it's exposed methods, it basically performs some processing and routes the data to a service associated with the data (different data will result in different routing). To ensure that the service runs as quickly as possible, each cycle of receiving, processing and routing of the data is handled by a seperate thread in the threadpool. could this be a problem arising from one thread calling proxyClass.Open() whilst another is already using it? would a lock block eliminate this problem, if indeed this is the problem?
thanks guys, - ive been workikng on this project for too long, and finally want to see the back of it - but this appears to be the last stumbling block, so any help much appreciated :-)
=========================================================================
thanks for highlighting that i shouldn't be using the using construct for WCF proxy classes. However the MSDN article isn't the most clearly written piece of literature ever, so one quick question: should i be using a proxy as such:
try
{
client = new proxy.DataConnectorServiceClient();
client.Open();
//do work
client.Close();
}
.................. //catch more specific exceptions
catch(Exception e)
{
client.Abort();
}
How are you using proxy? Creating new proxy object for each call. Add some code regarding how you use proxy.
Desired way of using proxy is for each call you create new proxy and dispose it once completed. You are calling proxy.open() for opened proxy that is wrong. It should be just called once.
Try using something like below in finally, as wcf does not dispose failed proxy and it piles up. Not sure it would help but give it a shot.
if (proxy.State == CommunicationState.Faulted)
{
proxy.Abort();
}
else
{
try
{
proxy.Close();
}
catch
{
proxy.Abort();
}
}
Why to do this?
http://msdn.microsoft.com/en-us/library/aa355056.aspx
Code you posted above would work but you will alway be eating exception. So handle wcf related exception in seperate catch and your generic catch with Excelion would abort then throw exception.
try
{
...
client.Close();
}
catch (CommunicationException e)
{
...
client.Abort();
}
catch (TimeoutException e)
{
...
client.Abort();
}
catch (Exception e)
{
...
client.Abort();
throw;
}
Also if you still want to use convenience of using statement then you can override dispose method in your proxy and dispose with abort method in case of wcf error.
And do not need to call .Open() as it will open when required with first call.
I'm assuming you're using .NET 3.5 or later. In .NET 3.5, the WCF ClientBase'1 class (base class for generated client proxies) was updated to use cached ChannelFactories/Channels. Consequently, unless you're using one of the Client use/creation strategies which disables caching (Client constructor that takes in a Binding object, or accessing one of a few certain properties before the backing channel is created), even though you're creating a new Client instance, it could very well still be using the same channel. In other words, before calling .Open(), always ensure you're checking the .Created status.
It definitely sounds like you've called Open() multiple times on the same object.
we hit the same roadblock as you sometime ago.
The issue with the using statement , is that if you get to a faulted state, it will still try to close at the end of the block. Another consideration, which was critical for us, is the cost of creating the proxy everytime.
We learned a lot from those blog posts:
http://blogs.msdn.com/wenlong/archive/2007/10/26/best-practice-always-open-wcf-client-proxy-explicitly-when-it-is-shared.aspx
and
http://blogs.msdn.com/wenlong/archive/2007/10/27/performance-improvement-of-wcf-client-proxy-creation-and-best-practices.aspx
Hopefuly it will help you as well.
Cheers, Wagner.