diff --git a/dlls/vbscript/interp.c b/dlls/vbscript/interp.c
index b328674..8ded5cd 100644
--- a/dlls/vbscript/interp.c
+++ b/dlls/vbscript/interp.c
@@ -112,7 +112,7 @@ static BOOL lookup_global_vars(ScriptDisp *script, const WCHAR *name, ref_t *ref
 
 static HRESULT lookup_identifier(exec_ctx_t *ctx, BSTR name, vbdisp_invoke_type_t invoke_type, ref_t *ref)
 {
-    ScriptDisp *script_obj = ctx->script->script_obj;
+    ScriptDisp *script_obj = ctx->code->script_obj;

Does it really use this script instead of global script global context? My guess would be that both should be looked up in this case. A test to clarify that would be nice.

+    if (!obj)
+    {
+        /* A persistent script with a dangling context calls these,
+           for some reason, even though it won't be executed. */
+        IActiveScriptSite_OnEnterScript(ctx->site);
+        IActiveScriptSite_OnLeaveScript(ctx->site);
+        return S_OK;
+    }

Is it just to satisfy a test? I'd suggest to leave it in todo_wine for OnEnterScript/OnLeaveScript. Otherwise, it would deserve a closer look to see if we can solve it more generally and avoid such special case.

         return hres;
 
+    /* Fix the dangling pointers to the old script dispatch */
+    LIST_FOR_EACH_ENTRY(code, &This->ctx->code_list, vbscode_t, entry)
+        if(code->script_obj)
+            code->script_obj = This->ctx->script_obj;

That's not pretty. Depending on result of test I mentioned earlier, we may want to simply not store global script context in vbscode_t (and only store named item-based script object).

Thanks,

Jacek