An integration embeds Studio as the content of a ContentControl that is the root of a view, as the Unreal plugin does (UNoesisStudioInstance: InitInstance() makes the ContentControl, Update() sets Studio::Create's element as its content). When another .noesis project is being opened, the integration releases the first Studio (the ContentControl's content set to null, which drops the last reference) and makes the second with Studio::Create into the same ContentControl, in the same view.

That second Studio crashes in about one run in three, with an access violation inside NoesisEditor.dll, either while the view updates it for the first time, or in the view's updates after it is released in turn. The same sequence with a new view (and a new ContentControl) for the second Studio didn't crash in 20 runs.

No renderer is needed to show it: the repro only updates the view.

The two projects are different (ReproA, ReproB).

Steps to reproduce

1. On Windows, with NOESIS_SDK_DIR set, run powershell -ExecutionPolicy Bypass -File build.ps1 in minimal/.
   It builds repro.cpp against Noesis.lib and NoesisEditor.lib and runs, on a fresh copy of project/
   each time:
   • repro A/ReproA.noesis B/ReproB.noesis same-view, 20 times;
   • repro A/ReproA.noesis B/ReproB.noesis new-view, 20 times (the control).

2. What same-view does, in one view whose root is a ContentControl, activated:

   1. root->SetContent(Studio::Create(A, options)), then 60 view->Update() calls;
   2. root->SetContent(nullptr) (Studio released), then 10 updates;
   3. root->SetContent(Studio::Create(B, options)), then 60 updates;
   4. root->SetContent(nullptr), then 10 updates; release the view; GUI::Shutdown().

   new-view releases the view and its root after step 2, and makes a new view (and root) for steps 3 and 4.

3. On a crash, an unhandled-exception filter prints the exception and the module and offset where it happened,
   and the process exits 3. build.ps1 exits 1 if any same-view run crashed.

Expected and actual

Expected: both cases make, update and release both Studios, every run.

Actual:

same-view: 20 run(s), 7 crashed, 13 clean
new-view: 20 run(s), 0 crashed, 20 clean

Keeping a reference to the first Studio across SetContent(nullptr) and releasing it 10 updates later:
still crashed (3 of 6), so it doesn't depend on Studio being destroyed inside the content change.