NullReferenceException from an impossible place?

Question

I want to know if anyone have ever encounter the same situation with me, that a NullReferenceException occurred from a place which is impossible.

Here's the exact same code piece that throws the exception:

private readonly StatePair[] _pairs =
{
  new StatePair(0),
  new StatePair(1),
  new StatePair(2)
};

public void CommitAll()
{
  var states = new State[_pairs.Length];

  // collect in reverse order
  for (var i = _pairs.Length - 1; i >= 0; i--)
  {
    // The only exit of CaptureState() method is a "new State()" statement.
    states[i] = _pairs[i].CaptureState();

    if (states[i] == null)
      throw new ApplicationException("The state captured is null.");
  }

  // commit in normal order
  foreach (var s in states)
  {
    if (s == null)
      throw new ApplicationException("The state is null.");

    s.Commit(); // *** NullReferenceException ***
  }
}

void Run() // Thread start
{
  while (true)
  {
    CommitAll();

    Thread.Sleep(200);
  }
}

Stacktrace:

System.NullReferenceException: Object reference not set to an instance of an object.
   at ...SystemUpdateCoordinator.CommitAll() in ...SystemUpdateCoordinator.cs:line 217
   at ...SystemUpdateCoordinator.Run() in ...SystemUpdateCoordinator.cs:line 22
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ThreadHelper.ThreadStart()

From the stack trace we can tell that s.Commit() throws NullReferenceException so it seems that s is null, but we've already check nulls and throw ApplicationException after each CaptureState(). If the CaptureState returns now, we should get an ApplicationException from the body of for instead of the NullReferenceException inside foreach.

The scare thing is, not all the users get the exception (it's an WPF application). We have about 10 users running this new version and only four of them meet the error, but it happened to them multiple times in two days. We're in a large firm so all the user's environment are restrictedly controlled and should be the same (.NET 4.0, Win 7).

Also here're some more details that might help:

Is multi-threading involved?

Yes, but the only part might be access concurrently is the MyPair object, and in CaptureState method it holds the writer lock from a ReaderWriterLockSlim. I've carefully reviewed the other methods in MyPair and all of them are protected by the reader lock of the same ReaderWriterLockSlim instance. Also, CaptureState() returns a new instance each time. All the rest variables are local (like s) and they won't have threading issue.

Any other related error happen at the same time?

Yes, actually there's another error occurred with the same new version of the application, which is an access violation error. It should be the same as this one, but I cannot make 100% sure that's the cause of the NullReferenceException for two reasons:

These two are not always happen together, although they happen together in most time.
If the concurrent GC bug corrupts the memory which brings the NullReferenceException, why it always happen to this the same statement? Why it doesn't happen in other places?

This issue bothers me for several days. I'm considering it as a runtime issue, but that's not something that I can prove or prove it wrong to others. I'm also trying to change the CommitAll() method a little bit to see if we can get different assembly code.

I'll post updates here if I have more info.

==== Update 1 (20150603) ====

Some people asked if the stark trace is accurate, and I think it is.

First of all there's no inlining happen to the CommitAll() method. I've dumped the assembly code and it calls the Commit method without inline.

Also, in the first place there's no throw new ApplicationException() checks here. The code is as simple as below since it's impossible to have null here:

public void CommitAll()
{
  var states = new State[_pairs.Length];

  for (var i = _pairs.Length - 1; i >= 0; i--)
  {
    states[i] = _pairs[i].CaptureState();
  }

  foreach (var s in states)
  {
    s.Commit(); // <- Line 209
  }
}

And the stack trace pointed to Line 209 which is the s.Commit(). So I added some null checks, and the stack trace becomes Line 217 which is exactly the new position of the same statement.

==== Update 2 (20150609) ====

The crash only happened once in the past week, but strangely the WER (Windows Error Reporting) didn't generate a mini crash dump. The event log still said:

Application: MyApp.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an internal error int the .NET Runtime at IP 000007FEEC0F25E8 (000007FEEC0B0000) with exit code 80131506.

It was different with the previous error logs said it was an access violation explicitly. The user said he doesn't see the WER dialog, so the application just crash suddenly.

So I can only check the old dumps from the old crashes.

One of the them says it was a "famous concurrent GC issue":

This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(2c90.381c): Access violation - code c0000005 (first/second chance not available)
clr!WKS::gc_heap::mark_object_simple+0x19a:
000007fe`eb13dc87 f70100000080    test    dword ptr [rcx],80000000h ds:00000000`00000000=????????
0:008> kb
RetAddr           : Args to Child                                                           : Call Site
000007fe`eb13dd8e : 00000000`b2103c48 00000000`2c92d850 00000000`2c92e9c0 00000000`b2023f08 : clr!WKS::gc_heap::mark_object_simple+0x19a
000007fe`eb1de7be : 00000000`b2103c48 00000000`2c92e9c0 00000000`2c92c2e0 00000000`2c92d7b0 : clr!WKS::GCHeap::Promote+0x79
000007fe`eb1e04ec : 00000000`2c92bec0 00000000`00000007 00000000`00000002 00000000`00000071 : clr!GcEnumObject+0x37
000007fe`eb1dfdd5 : 000007fe`00000000 00000000`00000000 00000000`00000000 000007fe`00000008 : clr!GcInfoDecoder::EnumerateLiveSlots+0x5dd
000007fe`eb1dea47 : 00000000`00080000 00000000`00000000 00000000`0230b540 00000000`2c92c2e0 : clr!EECodeManager::EnumGcRefs+0x13d
000007fe`eb09109f : 00000000`00000000 000007ff`02668548 00000000`2c92d7b0 00000000`00000000 : clr!GcStackCrawlCallBack+0x1e2
000007fe`eb090a6b : 00000000`2c92cb50 00000000`00000000 00000000`00000002 00000000`00000000 : clr!Thread::MakeStackwalkerCallback+0x2f
000007fe`eb0900f2 : 00000000`1fc3ab10 00000000`1fc3ab10 000000f8`00000000 00000000`00000002 : clr!Thread::StackWalkFramesEx+0x8d
000007fe`eb1de6e8 : 00000000`00000000 00000000`00000001 00000000`00000000 00000000`1fc3ab10 : clr!Thread::StackWalkFrames+0xb1
000007fe`eb13d831 : 00000000`00000000 00000000`2c92d880 00000000`00000000 00000000`023ade80 : clr!CNameSpace::GcScanRoots+0x1a4
000007fe`eb13de6d : 00000000`00000000 00000000`00000000 000007fe`eb8ea160 000007fe`eb13e6b6 : clr!WKS::gc_heap::mark_phase+0xe1
000007fe`eb29fcfd : 00000107`e77ad732 00000000`2c92d959 00000000`00000000 00000000`00000000 : clr!WKS::gc_heap::gc1+0xae
000007fe`eb13e44e : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : clr!WKS::gc_heap::garbage_collect+0x42e
000007fe`eb13d3fe : 00000000`00000030 00000000`00000002 000007fe`eb060000 00000000`00000000 : clr!WKS::GCHeap::GarbageCollectGeneration+0x14e
000007fe`eb13d12e : 00000000`0000001d 00000000`b2526b80 00000000`00000002 00000000`00000030 : clr!WKS::gc_heap::try_allocate_more_space+0x25f
000007fe`eb08d418 : 000007fe`e8b93028 00000000`00000030 00000000`00000002 00000000`2c92ddf0 : clr!FastAllocateObject+0x73e
Unable to load image C:\Windows\assembly\NativeImages_v4.0.30319_64\System.Core\84fa340f30d1921e0d8817f9344ee367\System.Core.ni.dll, Win32 error 0n2
*** WARNING: Unable to verify checksum for System.Core.ni.dll
000007fe`e8b25049 : 000007fe`e8b93028 00000000`b2526b00 00000000`b2526b00 000007fe`e8b24f9a : clr!JIT_NewFast+0xb8
Unable to load image C:\Windows\assembly\NativeImages_v4.0.30319_64\mscorlib\79d73b390cca60b8a1c1d1228c771f2f\mscorlib.ni.dll, Win32 error 0n2
*** WARNING: Unable to verify checksum for mscorlib.ni.dll
000007fe`ea18e458 : 00000000`b2526b00 00000000`00000004 00000000`b2526b00 00000000`00000000 : System_Core_ni+0x2a5049
000007fe`e8b37280 : 000007fe`e88849d8 000007fe`ea17efb0 00000000`0328be48 00000000`b24ee798 : mscorlib_ni+0x3ae458
000007ff`027790bc : 000007fe`e88dc738 00000000`b2524ed0 00000000`03137038 00000000`2c92dde8 : System_Core_ni+0x2b7280
000007ff`027789a0 : 00000000`00000000 00000000`00000000 000007ff`03b5ba48 00000000`067059f0 : 0x7ff`027790bc
...
000007fe`ea15169c : 00000000`04118280 00000000`0416ea50 00000000`0416ea50 00000000`00000000 : 0x7ff`024799c0
000007fe`ea1515ab : 00000000`0416ea50 00000000`00000000 00000000`00000000 000007fe`eb0a5a1f : mscorlib_ni+0x37169c
000007fe`ea1e6d8d : 00000000`0416ea50 00000000`00000000 00000000`00000000 00000000`00000000 : mscorlib_ni+0x3715ab
000007fe`eb09c9e4 : 00000000`0416ea78 00000000`00000000 00000000`00000000 00000000`00000000 : mscorlib_ni+0x406d8d
000007fe`eb09caf9 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : clr!CallDescrWorker+0x84
000007fe`eb09cb75 : 00000000`2c92ef48 00000000`00000001 00000000`2c92ef50 00000000`2c92f1a0 : clr!CallDescrWorkerWithHandler+0xa9
000007fe`eb09d0ac : 00000000`2c92f198 000007fe`ea0e4860 00000000`2c92f230 000007fe`e9eace7c : clr!MethodDesc::CallDescr+0x2a1
000007fe`eb16de50 : 00000000`2c92f640 00000000`2c92f220 00000000`2c92f6e0 000007fe`ea2bdf28 : clr!MethodDesc::CallTargetWorker+0x44
000007fe`eb1008e6 : 00000000`1fc3ab10 00000000`2c92f640 00000000`1fc3ab10 00000000`00001000 : clr!ThreadNative::KickOffThread_Worker+0x148
000007fe`eb10087b : 00000000`00000000 00000000`1fc3ab10 ffffffff`fffffffe 00000000`1fc3ab10 : clr!QueueUserWorkItemManagedCallback+0x92
000007fe`eb1007e8 : 00000000`00000480 00000000`004d0000 00000000`00000000 00000000`00000478 : clr!PEDecoder::CheckILOnlyImportDlls+0x294
000007fe`eb10094b : ffffffff`ffffffff 00000000`1fc3ab10 00000000`00000000 00000000`00000000 : clr!StubLinkerCPU::X86EmitPushReg+0x135
000007fe`eb16dca0 : 00000000`1fc3ab10 00000000`2c92fd80 00000000`00000001 00000000`00000000 : clr!COMArrayInfo::GetReference+0x12b
000007fe`eb22c736 : 00000000`28ef64b0 00000000`2c92f6f8 00000000`1fc3ab10 00000000`772cb98e : clr!ThreadNative::KickOffThread+0xc0
00000000`771959cd : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : clr!Thread::intermediateThreadProc+0x7d
00000000`772cb891 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0xd
00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x1d

The other one says something different:

This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(1714.ed4): Access violation - code c0000005 (first/second chance not available)
clr!VirtualCallStubManager::ResolveWorker+0x4a3:
000007fe`edb827d8 488b8980000000  mov     rcx,qword ptr [rcx+80h] ds:00000101`00000c84=????????????????
0:012> kb
RetAddr           : Args to Child                                                           : Call Site
000007fe`edb82713 : 00000000`00e2f360 00000000`2c50e740 00000000`00000000 800003ff`825b7314 : clr!VirtualCallStubManager::ResolveWorker+0x4a3
000007fe`edb43585 : 00000000`00000003 000007ff`0442a6b0 00000000`a004a410 00000000`8bd38210 : clr!VirtualCallStubManager::ResolveWorkerStatic+0x213
000007ff`02b416fb : 00000000`b7476e68 00000000`2c50e910 00000000`00e2bfd0 00000000`00000000 : clr!ResolveWorkerAsmStub+0x95
000007ff`02b41344 : 00000000`0a48bc20 00000000`a0444b88 00000000`8bd37108 000007fe`edbe45e4 : 0x7ff`02b416fb
...
000007ff`0245b040 : 00000000`000000fa 00000000`04157e38 00000000`045a09d0 00000000`00000000 : 0x7ff`0245b3e4
Unable to load image C:\Windows\assembly\NativeImages_v4.0.30319_64\mscorlib\79d73b390cca60b8a1c1d1228c771f2f\mscorlib.ni.dll, Win32 error 0n2
*** WARNING: Unable to verify checksum for mscorlib.ni.dll
000007fe`ea7e169c : 00000000`0431c4a0 00000000`045a09d0 00000000`045a09d0 00000000`00000000 : 0x7ff`0245b040
000007fe`ea7e15ab : 00000000`045a09d0 00000000`00000000 00000000`00000000 000007fe`edb85a1f : mscorlib_ni+0x37169c
000007fe`ea876d8d : 00000000`045a09d0 00000000`00000000 00000000`00000000 00000000`00000000 : mscorlib_ni+0x3715ab
000007fe`edb7c9e4 : 00000000`045a09f8 00000000`00000000 00000000`00000000 00000000`00000000 : mscorlib_ni+0x406d8d
000007fe`edb7caf9 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : clr!CallDescrWorker+0x84
000007fe`edb7cb75 : 00000000`2c50f168 00000000`00000001 00000000`2c50f170 00000000`2c50f3c0 : clr!CallDescrWorkerWithHandler+0xa9
000007fe`edb7d0ac : 00000000`2c50f3b8 000007fe`ea774860 00000000`2c50f450 000007fe`ea53ce7c : clr!MethodDesc::CallDescr+0x2a1
000007fe`edc4de50 : 00000000`2c50f860 00000000`2c50f440 00000000`2c50f900 000007fe`ea94df28 : clr!MethodDesc::CallTargetWorker+0x44
000007fe`edbe08e6 : 00000000`1c696620 00000000`2c50f860 00000000`1c696620 00000000`00001000 : clr!ThreadNative::KickOffThread_Worker+0x148
000007fe`edbe087b : 00000000`00000000 00000000`1c696620 ffffffff`fffffffe 00000000`1c696620 : clr!QueueUserWorkItemManagedCallback+0x92
000007fe`edbe07e8 : 000007ff`fffdc000 00000000`00000002 00000000`00000002 000007fe`f51f7163 : clr!PEDecoder::CheckILOnlyImportDlls+0x294
000007fe`edbe094b : ffffffff`ffffffff 00000000`1c696620 00000000`00000000 00000000`00000000 : clr!StubLinkerCPU::X86EmitPushReg+0x135
000007fe`edc4dca0 : 00000000`1c696620 00000000`2c50ff20 00000000`00000001 00000000`00000000 : clr!COMArrayInfo::GetReference+0x12b
000007fe`edd0c736 : 00000000`21062e70 00000000`2c50f918 00000000`1c696620 00000000`00000000 : clr!ThreadNative::KickOffThread+0xc0
00000000`76eb59cd : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : clr!Thread::intermediateThreadProc+0x7d
00000000`770eb891 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0xd
00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x1d

Also, the user is using .NET 4.0, but all developer's machines are using .NET 4.5 (but targets to .NET 4.0). That explains why the GC bug only happens on the user.

What is "State" object? Do you have sources for that or is that from some 3rd party library? — Ondra, Jun 02 '15 at 16:34
Does Commit() contain code which internally is returning the null ref (and s is in fact != null)? — James Harcourt, Jun 02 '15 at 16:34
Is that debug or release build? Inlining could lead you the wrong way — Ondra, Jun 02 '15 at 16:41
@Ondra I have the source code, but I don't think the exception is from `Commit()`. I've post the stack trace. Thanks. — Jeffrey Zhao, Jun 02 '15 at 16:41
@JamesHarcourt `Commit()` doesn't return a value, and the exception is not from that method. Also, internally I've also added some null checks, and it never hits. — Jeffrey Zhao, Jun 02 '15 at 16:42
@Ondra RELEASE build. I've verified by WinDBG and the `Commit()` method is not inlined (I can post the assembly code of `CommitAll()` if you need). The `Commit()` method is large and complex so it's not quite likely to be inlined. I think the x64 JIT doesn't optimize aggresively. — Jeffrey Zhao, Jun 02 '15 at 16:45
Can you show the code for `StatePair`, or at minimum `CaptureState` and maybe `Commit`? Everthing here looks A-OK, the problem must be on a deeper level. — Scott Chamberlain, Jun 02 '15 at 16:46
@ScottChamberlain The only exit of `StatePair.CaptureState()` is a `new State()` statement. `Commit` also have quite some null checks internally. If it's from deeper level, the stack trace should tell more. Also I've checked the assembly code of `CommitAll`, `Commit()` is not inlined. — Jeffrey Zhao, Jun 02 '15 at 16:51
Well that's great, but that does not help us. Your problem, as posted, does not have enough information to track down the problem. — Scott Chamberlain, Jun 02 '15 at 17:00
@ScottChamberlain After days of digging I start believing that's an runtime bug instead of code issue. Do you have any idea that how a deeper level implementation triggers the exception as I described? I think the stack trace has told us the clear position, or in which circumstance the stack trace misleads us? — Jeffrey Zhao, Jun 02 '15 at 17:24
@JeffreyZhao Maybe you need to set another property or pass a parameter for the object to commit. Also check if there is any inner exception description for the exception — Versatile, Jun 02 '15 at 21:10
Rule #1: it's almost _never_ a runtime bug. Rule #2: if you think you are seeing behavior that should be impossible, then either that behavior is not actually impossible, or you are not seeing what you think you are seeing. Assuming the code you posted is in fact the code being executed, then it _would_ be impossible for `s` to be `null`, and so the `NullReferenceException` is for some other reason. Lacking [a good, _minimal_, _complete_ code example](http://stackoverflow.com/help/mcve) that reliably reproduces the problem, there's nothing Stack Overflow can do to explain the problem. — Peter Duniho, Jun 03 '15 at 01:17
@Versatile No inner exception for a NullReferenceException. Thanks. — Jeffrey Zhao, Jun 03 '15 at 03:50
@PeterDuniho There's no "good minimal complete code example" I can give to reliably reproduce the problem, since I don't even have it. It only happens to several users randomly. That's the really hard issue in real world, isn't it. Also, I wouldn't start thinking it's a runtime bug until I have dig into the details for days, and a runtime bug has already been come up with it. — Jeffrey Zhao, Jun 03 '15 at 03:51
At the very least, you can provide **a _minimal_ and _complete_ code example** that reliably causes the problem on some subset of your users. This issue obviously occurs repeatedly over time, otherwise you wouldn't be asking about it. You haven't shared enough code here for anyone else to know what the problem even _might_ be. — Peter Duniho, Jun 03 '15 at 04:01
@PeterDuniho Sorry I don't have it either. The issue didn't happen yesterday. No one's crashed anymore with nothing changed. Also, it's really hard to get the code example, since the user is doing very important business that none of the users would help us running tests. QA could help, but they never see that. I know it's hard to get some idea for the limited information but that's also what I can get. I'm now asking a crash dump for further investigation and may be I would come back with more information. I was hoping that anyone here has meet the similar case and share some hits. — Jeffrey Zhao, Jun 03 '15 at 04:20
If you could reproduce it: Create Crashdump with full managed memory! Load it with VisualStudio Ultimate! Check Parallel Stack and Memory Dump. - or - fill your code with trace (but usually it hides your error) — sac1, Jun 03 '15 at 07:10
might be worth to show what happens inside Commit() and how you start the thread at all — fuchs777, Jun 03 '15 at 07:27
by the way you describe it, it sounds like it's specific to the user. Meaning, the users affected by this bug do *something* different from anyone else. Maybe they click faster (that was actually a problem for me once) than anyone else or do something in a weird order...anyway, since you've Multithreading in there, why aren't you putting `lock` statements all over your code? — Steffen Winkler, Jun 03 '15 at 11:25
@SteffenWinkler `ReaderWriterLockSlim` allows the reader threads to access the same resource in parallel, which brings better concurrent level. This object has only three methods (including `CaptureState`) and the other two are protected by a reader lock. It's quite simple that I don't find incorrect usage of the RW lock. — Jeffrey Zhao, Jun 03 '15 at 16:33
@JeffreyZhao had to read up on that ReaderWriterLockSlim. Seems complicated and errorprone (enter a ReadLock, exit a WriteLock for example). Also it seems to have some overhead which means one has to evaluate wether it's performing better or worse than lock() in a specific situation. Anyway, there is no ReaderWriterLockSlim in your code. Nothing at all. You should lock the body of the foreach loop at the very least. — Steffen Winkler, Jun 03 '15 at 20:29
@SteffenWinkler Let's just assume that `ReaderWriterLockSlim` has worse performance than `lock`, it doesn't mean there's a threading issue here. We cannot just "lock" everything without indicating an existing Threading issue. — Jeffrey Zhao, Jun 04 '15 at 02:38
is this problem reproducible currently? (even if it's just on the PC of one user) — Steffen Winkler, Jun 04 '15 at 11:12
@SteffenWinkler It was reproduced once in the past week, but it doesn't have crash dump. BTW I've updated some detail from old crash dumps. — Jeffrey Zhao, Jun 09 '15 at 15:56
Since you have access violations too, it's worth noting that an access violation at a low address that is caught by .NET will produce a `NullReferenceException`, because that's how null reference exceptions are detected. — Jon Hanna, Jun 10 '15 at 03:02
@JonHanna But another question is, why it's always the same line trigger the access violation or `NullReferenceException`? — Jeffrey Zhao, Jun 10 '15 at 03:54
I'm still convinced that it's a multithread issue because you aren't using lock statements where you access/change that. You are checking the object before accessing it - it's not null. You access it, it's null. You try to reproduce it, but can't or only on one computer. Seen it dozens of times, always multithread problem because of insufficient locking. And it's always the first thing to be excluded, too. And I include myself here: People always think 'nah, it can't be that.'. It is. — Steffen Winkler, Jun 10 '15 at 07:01
Are you running any native code, COM objects, Office Interop code? — John Saunders, Jun 10 '15 at 07:21
@SteffenWinkler Not using `lock` doesn't means there's a threading issue (actually I've also make it using `lock` now and it still happens). On the other hand, threading issue shouldn't trigger access violation. Also, the variable here is local and it doesn't have multiple threading access it. — Jeffrey Zhao, Jun 10 '15 at 07:39
@JohnSaunders Yes, some vender product dlls are using native code, but they have been used for quite a long time. Nothing's upgraded in new application release. — Jeffrey Zhao, Jun 10 '15 at 07:43
Threading issue with native code that isn't properly tested to run in a mult-threaded environment will _absolutely_ cause an access violation. — John Saunders, Jun 10 '15 at 07:45
@JohnSaunders That's a possibility but quite unlikely, since 1) the code is not touched for months, 2) the code with multi-threading doesn't use the native code 3) with plenty of code review and simplification, we don't see the threading issue in the code. — Jeffrey Zhao, Jun 11 '15 at 02:17
If the native code is being used in more than one thread, _ever_, then it can be a problem. Recall that much native code does not expect to _ever_ run in more than a single thread. I had this problem once with a piece of "thread-safe" native code which assumed it was being called from a single-threaded C program. It then proceeded to trash the C runtime library heap when run from an ASP.NET application. Just beware of violating the assumptions of the original developers. Unless they expected to run in WPF, I'd be concerned. — John Saunders, Jun 11 '15 at 03:14
@JohnSaunders The vender dll is documented as not thread-safe so we didn't use it with multi-threading. I agree with you that native code might trigger access violation, but unfortunately I don't know how to prove it to others. From the stack trace of crash dump, it seems that the issue is the famous bug in .NET 4, so I'm trying to verify if upgrading to 4.5 can fix the issue. — Jeffrey Zhao, Jun 11 '15 at 05:15
Could you provide a link to this famous bug? I'm not sure I've heard of it. — John Saunders, Jun 11 '15 at 05:25
@JohnSaunders We can find many questions for the issue even in StackOverflow. The KB is https://support.microsoft.com/en-us/kb/2679415 — Jeffrey Zhao, Jun 11 '15 at 05:34
See also http://stackoverflow.com/questions/19154014, though with the same caveat as the similar one linked in your original question. — whybird, Jun 11 '15 at 06:42

NullReferenceException from an impossible place?

0 Answers0

Linked