|
0xc0000005 is an access violation, quite often caused by dereferencing a null pointer.
|
|
|
|
|
Hi Luc
Thanks for the reply.
Unfortunately in my case it may not be that simple?
As an example, for my Products screen, this can happen when they add a product or even save.
An end user can even close this screen and save successfully, go to another screen, then the dreaded Native Exception Error.
The above is all handled by managed code, C#. When disabling the unmanaged code I still get these Native Exception Errors, although they seem to be less common - so in this instance I'm not using any pointers.
These crashes are random and intermittent. There seems to be no pattern. I have about 35 end users working with this software and for some they don't get any of these Native Exception Errors. Others will get this error once a week. Still others will get it 3 times a day!
They all use the software as much as each other as I keep tabs on their usage.
Hope this makes sense.
Mark Eaton
|
|
|
|
|
Hi Marc,
if the problem occurs even when the application is running without using unmanaged code
at all, it is a mystery. If some unmanaged code is involved, a crash (even a delayed one)
is possible when a fundamental mistake is present such as:
- dereferencing a null pointer
- using incorrect calling conventions resulting in stack problems
[DllImport("kernel32.dll", CallingConvention=CallingConvention.StdCall)]
- not pinning the managed objects
- and, of course, all kinds of bugs in the unmanaged code itself.
I would suggest putting try-catch constructs around every PInvoke call, and
logging all exceptions in order to track down the problem(s).
Hope this is useful to you.
Luc Pattyn
|
|
|
|
|
Hi Luc
Thanks for the quick reply.
I hope there isn't bugs in the unmanaged code as it is 3rd party software.
But one thing you suggested that I'm not doing enough is try/catch blocks around the unmanged code.
I will also double check the calling convections.
I don't understand "not pinning the managed objects". What does this mean?
Thanks again for you help.
Kind regards
Mark Eaton
|
|
|
|
|
Hi Mark,
when passing a managed object's pointer to unmanaged code, you better make sure the object
does not get moved around by the garbage collector while in use by unmanaged code.
The following code snippet illustrates this:
// pass a managed byte array to an unmanaged C/C++ function:
public int Read(byte[] data, int len) {
try {
// check boundaries (bad len would cause an exception !)
data[0]=0;
data[len-1]=0;
// pin the array in memory, get its base adr
GCHandle dataHandle=GCHandle.Alloc(data, GCHandleType.Pinned);
int dataPtr=dataHandle.AddrOfPinnedObject().ToInt32();
int result=nativeCall(dataPtr, len);
dataHandle.Free(); // release the pinned array
return result;
} catch (Exception exc) {...log.and.return.errorcode...}
}
The above is the design pattern I often use for passing arrays to unmanaged C code.
Best regards,
Luc Pattyn.
|
|
|
|
|
Hi Luc
This hasn't even occurred to me. I appreciate the code example as well.
If you have any other suggestions I am happy to hear them.
Unfortunately it will take some days to get my code fully tested but I will try everything you suggested.
Kind regards
Mark Eaton
|
|
|
|
|
I Have a window 2003 server machine. I Installed visual studio.NET 2003 on my machine.
In Microsoft visual studio .NET 2003 a error is occured ,
when I want to create a new project in ASP.NET Web
Application visual studio .net has dected that the web
server is runing ASP.NET version 1.0.
The web application you are creating or opening can be
configured to be complaint with ASP.NET 1.0 .
however , the application will not able to use new
features from ASP.NET 1.1 .
So I can't work on my machine for Dot Net .
Plz sugess me for this .
Thanks all off u .
nilesh
|
|
|
|
|
Is IIS installed and running?
Mike Lasseter
|
|
|
|
|
Bah, I've been working on this forever now and I can't seem to find why this error happens.
Uncaught exception (see the 'inner exception' below) has suspended an instance of service 'Ingramtest.Order(1359c91a-86bf-d041-3a7a-ef48ebb10fa7)'.
The service instance will remain suspended until administratively resumed or terminated.
If resumed the instance will continue from its last persisted state and may re-throw the same unexpected exception.
InstanceId: 198894a5-41a3-407a-bc2f-2e492cc9ed03
Shape name: Send_7
ShapeId: efb1d8a7-4fa2-4f3d-b135-7119a999de7d
Exception thrown from: segment 1, progress 36
Inner exception: Exception occurred when persisting state to the database.
Exception type: PersistenceException
Source: Microsoft.XLANGs.BizTalk.Engine
Target Site: Void Commit()
The following is a stack trace that identifies the location where the exception occured
at Microsoft.BizTalk.XLANGs.BTXEngine.BTXXlangStore.Commit()
at Microsoft.XLANGs.Core.Service.Persist(Boolean dehydrate, Context ctx, Boolean idleRequired, Boolean finalPersist, Boolean bypassCommit, Boolean terminate)
at Microsoft.XLANGs.Core.ServiceContext.PendingCommit(Boolean ignore, XMessage msg)
at Microsoft.XLANGs.Core.ExceptionHandlingContext.PendingCommit(Boolean ignoreCommit, XMessage msg)
at Microsoft.BizTalk.XLANGs.BTXEngine.BTXPortBase.SendMessage(Int32 iOperation, XLANGMessage msg, Correlation[] initCorrelations, Correlation[] followCorrelations, SubscriptionWrapper& subscriptionWrapper, Context cxt, Segment seg, ActivityFlags flags)
at Microsoft.XLANGs.Core.PortBase.SendMessage(Int32 iOperation, XLANGMessage msg, Correlation[] initCorrelations, Correlation[] followCorrelations, SubscriptionWrapper& subscriptionWrapper, Context cxt, Segment seg)
at Ingramtest.Order.segment1(StopConditions stopOn)
at Microsoft.XLANGs.Core.SegmentScheduler.RunASegment(Segment s, StopConditions stopCond, Exception& exp)
Additional error information:
A batch item failed persistence Item-ID 2c1195f7-fb56-4043-86b6-4aeeae7f8dd5 OperationType MAIO_CommitBatch Status -1061151960 ErrorInfo An error occurred when accessing the part data or one of its fragments. The part data or fragment may not exist in the database. .
Exception type: PersistenceItemException
Additional error information:
Failed to publish (send) a message in the batch. This is usually because there is no one expecting to receive this message. The error was An error occurred when accessing the part data or one of its fragments. The part data or fragment may not exist in the database. with status -1061151960.
Exception type: PublishMessageException
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
WM.
What about weapons of mass-construction?
|
|
|
|
|
I found the problem, at least I think I did.
The problem ocurred when I copied a message so that I had two messages of the same type. Removing the duplicate solved the problem.
But now there's a different problem, but I will contact MS about that, since there's a hotfix for it
WM.
What about weapons of mass-construction?
|
|
|
|
|
what is GAC(Global Assembly Cache)
Does any one know what is meant by digitally signing an assembly.
I any of you can provide useful link, i will be thankful to that person.
Warm Regards,
Mushq
|
|
|
|
|
The Global Assembly Cache is a location which the .NET Framework looks in for shared assemblies (used by more than one program). It looks here first for assemblies which have a strong name, which is a name that includes the version number, culture, and a public key token which identifies the publisher of that assembly. If not found in the GAC it will then fall back to the application directory and directories under it in the same way as for non-signed assemblies.
To ensure that the assembly has not been tampered with, it is digitally signed. This means that public-key cryptography has been used to attach a digital signature to the assembly. A hash (a fixed-size value generated by a one-way function which is highly likely to be unique to a particular input file) is generated, then that hash is encrypted with the publisher's private key to form the signature. On the end-user's system, the publisher's corresponding public key can then be used to decrypt the signature and compare it with re-computing the hash value. If they match, the assembly has not been altered and can potentially be assigned a level of trust as appropriate.
The public key token is a hash of the public key data, used because it is significantly shorter than the public key itself. If I recall correctly, the public key itself is actually attached to the binary since it is required for checking the signature.
Note that although this is a public/private key pair is used, this does not mean the key used has to be part of a public key infrastructure. You don't need to buy one from a Certification Authority, as you do with SSL or Authenticode code-signing certificates - you simply generate a key pair using the sn.exe utility.
|
|
|
|
|
I am using .net CF with PPC 2003 and SQLCE 2.0. I am having trouble getting a simple pull of a table to the emulator. I am getting an HRESULT error 28037. I am not sure what to do. Here is a clip of the code. Does anyone have an idea?
thanks,
Saurabh Gupta
Software Engineer
|
|
|
|
|
Hi All,
I want to read more about how framework 2.0 work - i looked in Microsoft site but i don't find anything that will explain to me what to do to work in better performance and how all work in the background.
Thanks for any help.
|
|
|
|
|
|
There is no site that can explain ?
|
|
|
|
|
There will be articles but they wiil be scattered around.
Kevin
|
|
|
|
|
try
{
...
XmlReader rdr = XmlReader.Create(input_XML_file, settings);
}
catch (Exception ex)
{
...
}
if there's a problem reading/parsing the file, and the code ends up in the catch, the file is left open (can't rename, delete, move, etc). shutting down VS and all of its little spawned web servers doesn't help.
by changing the code to open the file as a StreamReader, then using that Stream as the source to XmlReader.Create, i can explicitly Close the Stream in the catch, and the file is not left locked.
|
|
|
|
|
No, it's not a bug. You left it open, so it works exactly as it should.
The XmlReader class implements IDisposable, so you can use that to make sure that it's closed:
using (XmlReader rdr = XmlReader.Create(input_XML_file, settings)) {
...
}
---
b { font-weight: normal; }
|
|
|
|
|
i didn't leave anything "open", because i didn't open anything. i gave XmlReader a filename and XmlReader opened the file. XmlReader then left the file open after it threw an exception. and XmlReader left the file open even after the program exited - not me.
|
|
|
|
|
Chris Losinger wrote: i didn't leave anything "open", because i didn't open anything. i gave XmlReader a filename and XmlReader opened the file. XmlReader then left the file open after it threw an exception. and XmlReader left the file open even after the program exited - not me.
If you think like that, then you never open anything ever. You just give a filename to the File.Open method and it opens the file. You just give a connection string to the SqlConnection object, and it opens the database connection.
Just because you don't call the interrupt that opens the file yourself, doesn't free you from the responsibility to make sure that it's closed properly.
---
b { font-weight: normal; }
|
|
|
|
|
that's just silly. surely you can see the difference between a function called "File.Open" and one called "XmlReader.Create".
in one case the caller expects and gets an open file, because that's the reason for calling the function. in the other, the caller doesn't get an open File object, has no access to any open File object, and isn't expecting one - the opened file is an undocumented side-effect.
Guffa wrote: Just because you don't call the interrupt that opens the file yourself, doesn't free you from the responsibility to make sure that it's closed properly
if it's the caller's responsibility that the XmlReader user should close the file, then why does XmlReader close the file by itself in some situations but not others; and why does the MSDN fail to mention anything about this behavior, or this "responsibility" ?
at best, this function is inconsistent in behavior and poorly-documented.
|
|
|
|
|
Chris Losinger wrote: then why does XmlReader close the file by itself in some situations but not others
Because it has a finalizer which closes the file for you, but this is not deterministic - you cannot predict when this will occur.
Anything which implements IDisposable should be Dispose d by the programmer when the object has been finished with. That's the rule I follow. You can use a using block to automatically call Dispose when execution leaves the block - this includes exits due to exceptions as well as normal program execution.
Finalizers run on a single separate finalizer thread, which processes a queue of finalizable objects. An object with a finalizer gets pushed onto the end of the queue when the garbage collector runs, unless GC.SuppressFinalize has been called on the object (this is usually done by the implementation of Dispose ). The finalizer thread runs the finalizers asynchronously with respect to the rest of the program. Only when the finalizer has run can the memory that the object was occupying be freed. Best practice is to avoid having objects end up in the finalizer, to reduce the memory load and to avoid synchronization problems with finalizers.
|
|
|
|
|
I don't know if the object representing the file has a finalizer, but if it does, then I don't think XmlReader would have one. As you might be knowing, the order in which finalizers are called is undefined, so it's possible the file object gets finalized before the XmlReader instance does.
|
|
|
|
|
OK, XmlReader itself does not have a finalizer. The FileStream which is managed by the XmlReader does. The rest of my comments still apply - you have to dispose anything that's disposable.
|
|
|
|
|