better comment

ee/wmi/wmi.go

@@ -153,9 +153,16 @@ func Query(ctx context.Context, slogger *slog.Logger, className string, properti
 	}
 	defer serviceRaw.Clear()
 
-	// the memory of result is released by `defer serviceRaw.Clear()` above,
-	// on windows arm64 machines, calling `service.Clear()` after `serviceRaw.Release()`
-	// would cause a panic
+	// In testing, we find we do not need to `service.Release()`. The memory of result is released
+	// by `defer serviceRaw.Clear()` above, furthermore on windows arm64 machines, calling
+	// `service.Clear()` after `serviceRaw.Release()` causes a panic.
+	//
+	// Looking at the `serviceRaw.ToIDispatch()` implementation, it's just a cast that returns
+	// a pointer to the same memory. Which would explain why calling `serviceRaw.Release()` after
+	// `service.Clear()` causes a panic. It's unclear why this causes a panic on arm64 machines and
+	// not on amd64 machines.
+	//
+	// This also applies to the `resultRaw` and `results` variables below.
 	service := serviceRaw.ToIDispatch()
 
 	slogger.Log(ctx, slog.LevelDebug,
@@ -170,9 +177,7 @@ func Query(ctx context.Context, slogger *slog.Logger, className string, properti
 	}
 	defer resultRaw.Clear()
 
-	// the memory of result is released by `defer resultRaw.Clear()` above,
-	// on windows arm64 machines, calling `resultRaw.Clear()` after `result.Release()`
-	// would cause a panic
+	// see above comment about `service.Release()` to explain why `result.Release()` isn't called
 	result := resultRaw.ToIDispatch()
 
 	if err := oleutil.ForEach(result, handler.HandleVariant); err != nil {