"Object reference not set...." in vault explorer

An Object is an instance of a Class , it is stored some where in memory. A reference is what is used to describe the pointer to the memory location where the Object resides. The message "object reference not set to an instance of an object" means that you are referring to an object the does not exist or was deleted or cleaned up. It's usually better to avoid a NullReferenceException than to handle it after it occurs. To prevent the error, objects that could be null should be tested before being used.

if (mClass != null)
{
// Go ahead and use mClass
mClass.property = ...
}
else
{
// Attempting to use mClass here will result in NullReferenceException
}

That type of error can have a million and one root causes, without knowing the code detail any further : (
For instance it's very commonly seen in occasions where either the local system, or remote system, is either bottlenecked, or behaving in a bursty manner, or messages are unexpectedly not being received or sent, or the software is running much faster or much slower than usual.

In these cases, objects may be deleted at the wrong time, or accessed when it's no longer appropriate, due to multiple state machines (say local and remote, or ingress and egress or anything else) being in unexpected combination of states with respect to each other. For sure it should be coded better to continue operations or handle reattempts or better error handling and reporting, but the reason these errors are often seen is simply because race conditions are unexpected, and often some development teams won't test that as well as they could, since it often entails deliberately introducing delays or load just to simulate possible conditions users may experience with (say) slower or faster computers, or slower or faster communication paths, or broken network connections, missing or moved URLs and so on.

That type of error can have a million and one root causes, without knowing the code detail any further : (
For instance it's very commonly seen in occasions where either the local system, or remote system, is either bottlenecked, or behaving in a bursty manner, or messages are unexpectedly not being received or sent, or the software is running much faster or much slower than usual.

In these cases, objects may be deleted at the wrong time, or accessed when it's no longer appropriate, due to multiple state machines (say local and remote, or ingress and egress or anything else) being in unexpected combination of states with respect to each other. For sure it should be coded better to continue operations or handle reattempts or better error handling and reporting, but the reason these errors are often seen is simply because race conditions are unexpected, and often some development teams won't test that as well as they could, since it often entails deliberately introducing delays or load just to simulate possible conditions users may experience with (say) slower or faster computers, or slower or faster communication paths, or broken network connections, missing or moved URLs and so on.