DllMain Thread

[CoolGamer]

UCyborg,

I need your help with another potential DLL Main issue. Can you take a look at the following benchmark:

XL-R8R Tech benchmark DX7 by MadOnion (FutureMark)
https://www.youtube.com/watch?v=LEvU380DM20
http://downloads.guru3d.com/xL-R8R-download-179.html

It is supposed to be based on 3DMark2000 engine. It works fine natively on my Windows 7 Ultimate 64bit OS. I don't even need compatibility mode. But it silently crashes without an error when I try to run it via dgVoodoo.

[UCyborg]

Is this hosted anywhere else besides Guru3D? Can't download it from either mirror.

[CoolGamer]

Yes, It seems like XL-R8R Tech benchmark is also hosted on FutureMarks's legacy webpage
https://www.futuremark.com/benchmarks/legacy
http://d1heja5wzvsadj.cloudfront.net/xl-r8r.exe

It is also available on this website:
https://www.computerbase.de/downloads/b ... rk-xl-r8r/

It might not be a Dll Main issue since XL-R8R works fine natively. Maybe it is something similar to the issue that you figured out in Final Reality Demo where dgVoodoo was returning incorrect messages to the application.

[lowenz]

Maybe it's a good thing to upload all the (updated) packages in a Mega(.nz) folder, and not as post attachments.

[UCyborg]

My main Windows 10 installation crapped itself the previous weekend, so couldn't take a look back then. It does appear to be DllMain issue, so probably the same remedy will help. Note that there are circumstances where it works natively, but not always. Usually it still works with NVIDIA drivers.

[UCyborg]

Never mind, it's not DllMain. It tries to query user mode driver DLL info, which doesn't work through dgVoodoo, so it throws exception and quits. It calls GetFileVersionInfoEx on non-existent file named dgVoodoo, which fails. Natively, the file would be nvd3dum.dll on NVIDIA hardware.

[mirh]

As a point of interest, Compatibility Administrator 5.6 has 2 annoying bugs, I seem to remember uninstalling database from the system, making modifications to the copy you have elsewhere (you can't modify installed version) and installing it again seems to fail, unless you close and re-open program when you want to re-install database.

Sometimes you need to disable entries in system database because some things aren't needed anymore. For example, alt-tab combination is needlessly blocked for Drakan: Order of the Flame. There is a bug in 5.6 version of the program that writes this information in the wrong part of the registry on 64-bit systems, so it's impossible to disable certain entry without manually inspecting registry and putting the information in correct place. It writes to HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\AppCompatFlags instead of HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags This was solved with later versions, but they don't work on Windows 7.

While we are at it, I'd also like to "sponsor" another bug with the "compatibility environment", on 10.
https://social.msdn.microsoft.com/Forum ... e-disabled

EDIT: btw, in which OS this dllmain bug would appear?

[UCyborg]

While we are at it, I'd also like to "sponsor" another bug with the "compatibility environment", on 10.

I don't think it's specific to Windows 10. The problem is that the setting is being cached in another part of registry if application was launched at least once: HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Compatibility Assistant\Store

The easiest solution is actually right-clicking on the .exe->Properties->Compatibility->OK. This causes the settings to reload and it should work afterwards.

There is a similar problem if you modify application resources with Resource Hacker, application manifest to be precise. It won't be picked up the next time it's launched. This can be helped by deleting the associated PF file from C:\Windows\Prefetch

With both things, changed last modification date of the file forces the refresh (Resource Hacker doesn't change the date).

btw, in which OS this dllmain bug would appear?

It's OS independent, the rules about DllMain apply to all systems.

[UCyborg]

I overlooked that you tried to mess with compatibility settings and it didn't work, even though it should. Quake 4 also has RunAsHighest applied by default. I can't reproduce the issue on Creators Update, Compatibility tab trick seems to work here. consent.exe isn't triggered anymore, though the UAC icon remains unless you clear the icon cache.

[Nucleoprotein]

EDIT: btw, in which OS this dllmain bug would appear?

Not really a bug, by design DllMain is very limited in functionality, such things should not be done in DllMain.

[mirh]

I overlooked that you tried to mess with compatibility settings and it didn't work, even though it should. Quake 4 also has RunAsHighest applied by default. I can't reproduce the issue on Creators Update, Compatibility tab trick seems to work here. consent.exe isn't triggered anymore, though the UAC icon remains unless you clear the icon cache.

Well, I just tried with latest build and it's still broken. Yes, I cleaned both prefetch and "compatibility cache".
I speculate that ME being a fully fledged vista-compliant executable, with a manifest (that lovely would even have requestedExecutionLevel level="asInvoker") might explain the discrepancy.

I wonder if the bug might not happen just in light of this then, thus possibly in all Windows too, or if the problem couldn't still be W10-something-specific.
After some guess work with 'strings' over whole Windows folder, prcomon to see which svchost process read the registry entries, procexp to see which thread/address is responsible, and CFF explorer to see which candidate dll called RPCR (since AppInfo!aienabledesktoprpcinterface)...
If anybody wants to take a look to "loading mechanism", I think it should be located in C:\Windows\AppPatch\AcGenral.dll

[mirh]

Big news guys.
Microsoft support department is the most retarded place on earth.

Long story short, I had the luck to get in personal touch with a local Windows engineer, that could fast track my issue to official consumer support.
And it sucked so hard.
My. Program. Is. Made. To. Launch. As. Administrator. Me. Not. Want. Dis. Interference.
And guess what? They told my Mass Effect was a third party product they couldn't help me to support.
Which I guess is reasonable, because people are so dumb, and if I were the face of the most complex(?) and used OS on earth I swear I'd be numb too.

So what? I won lottery twice, and was redirected to freaking business support for free!
I told them about the compatibility engine, I underlined that even their group policy editor was broken because setting weren't being read, and you can even check my test-case on github now.
Result? Mass Effect is not supported by EA after Windows Vista, thanks for joining us.
And I mean, this wasn't the immediate response. This only came at the end of hours of phone discussing, weeks of waiting "tests" and crap.

It's mind fucking blowing how careless they are.
And if this happened with direct 1:1 tete-a-tete conversation, god only knows what they understand from forum posts.

[lowenz]

Welcome to the real world

[UCyborg]

Speaking of Microsoft, I found an interesting bug in their Desktop Window Manager. If you use PeekMessage in a message loop like this (just a dummy example code to emphasize the point):

Code: Select all

while (1)
{
   if (PeekMessage(&msg, NULL, WM_KEYFIRST, WM_KEYLAST, PM_REMOVE) || PeekMessage(&msg, NULL, WM_MOUSEFIRST, WM_MOUSELAST, PM_REMOVE))
   {
      if (msg.message == WM_QUIT)
         break;
      TranslateMessage(&msg);
      DispatchMessage(&msg);
   }
   else if (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
   {
      if (msg.message == WM_QUIT)
         break;
      DispatchMessage(&msg);
   }
   Sleep(1);
}

The Desktop Window Manager will consider the app unresponsive 5 seconds after it loses focus and replace its window with a ghost copy that does not respond to user input. DWM may also try replacing the app's window with a ghost window when it does have focus, so one may see a window sort of flash on a 5 second interval.

It does not happen if you do one call to PeekMessage call in a loop with wMsgFilterMin and wMsgFilterMax parameters set to 0, or disable process window ghosting with either NoGhost compatibility shim or a call to DisableProcessWindowsGhosting. It may not happen if some 3rd party window managing utility is running.

I know Surreal Software's games have their message loop written similarly, using the filtering feature of the PeekMessage API and without unofficial patches, they act weird in windowed mode with desktop composition enabled.

But it's not the bug in the games themselves, as long as you eventually call PeekMessage without a filter, you've done it correctly according to API documentation.

The bug exists since Windows Vista and is probably still present on Windows 10, I know it's in the build 15063 and I doubt it's been fixed in today's actual builds.

My. Program. Is. Made. To. Launch. As. Administrator. Me. Not. Want. Dis. Interference.

Since you mentioned the manifest, I think asInvoker would translate to normal user rights under usual circumstances. highestAvailable should elevate to admin level though, at least if user is admin. It may ask for another user's credentials if he's not, but I'm not 100% certain. Really weird.

Another weird thing comes to mind, one Windows 10 PC at home, I could never reset its desktop icon layout completely (haven't purged the user account, that's no way, even though it might work). There is a key that stores it and deleting it made the system forget the layout, but the bug that creeped in some time ago, preventing from putting any icon in the lower left corner, persists.

I remember reading the funniest thing on PCGamingWiki.

Problem: Low FPS in Wolfenstein: The New Order
1st solution: Run the game as administrator

And this is a newer game that doesn't try to write its settings and saves to restricted locations. I know when it comes to old games, some will try to write some things in registry under HKEY_LOCAL_MACHINE. Microsoft's answer to this so the write doesn't fail when run with normal privileges is file/registry virtualization. But under some circumstances, registry virtualization fails to work properly and game in question fails to read its data back. I think it can happen after a normal shutdown (rather than hybrid one) or reboot, at least I remember it happening long time ago on Windows 8.1. Since then I just patch my games to write to HKEY_CURRENT_USER. A nice thing about keeping everything per-user, if you wipe user profile, all applications' user data should be gone.

Sucks to hear about what kind of support you get from MS. I might put that little program which snippet I've shown above on GitHub, though I don't feel like contacting anyone at MS. I wonder if Raymond Chen can be contacted somehow, he could write a story about that bug on his blog.

I remember reading about another problem with DWM, someone was trying to get rid of flickering in his program without much success. There used to be the link with the demo program and there was indeed a problem. What's interesting, I found out the flicker could be prevented by applying NoGDIHWAcceleration shim. But that's a workaround rather than a fix. It seems the old Pinball game that was bundled with Windows XP is also affected by DWM's oddities, when the ball is moving at high speed, it looks like as if it disappeared temporarily. NoGDIHWAcceleration seems to help.

OK, after so much off-topic babbling, here's something on-topic: There is DelayAppDllMain shim in Compatibility Administrator, but it doesn't help with our DllMain problem. End of story. Goodbye. The end.

[mirh]

Well, yeah, we have the dumbest of the fixes on the wiki.
Sometimes legitly (like.. check game cache), but mostly just half-assed unreasoned and untested "my cousin told me" solutions.
E.g. mass effect used to have exactly that "run as admin" fix universally, before I understood what the real problem was about.

Anyway, you can at any time check my testcase for the compatibility problem here.
10KB is all you need to trigger it.
EDIT: oh, by the way, another theory could be microsoft just screwed the policy altogether in W10. Purposely or by mistake, I dunno.
Guess like I could look for an enterprise copy of windows to check.

Last but not least, that DWM madness remembered me of the problem pcsx2 was having.

[lowenz]

Don't know if this is the right thread but Max Payne 1 + dgVoodoo2 (last WIP) D3D8.dll can be hooked by ReShade's "d3d11.dll" but NOT "dxgi.dll" (only the name is different)
Why this strange behaviour? Never seen before.

Maybe the Win10 x64 Fall Creators's handling is different?

Max Payne 2 can still be hooked by dxgil.dll

[UCyborg]

@mirh

Tried your test program, it indeed crashes and I can't find the way to stop it from running as admin after I've already ran it once, besides renaming it. I seem to remember being able to clear admin flag from the 8.1 system like this:

1. Disable compat flags with Compatibility Administrator.
2. Clear .exe related prefetch data.
3. Clear registry data (Compatibility Store).
4. Reboot.
5. Set program to run as admin via .exe Compatibility tab and confirm, then undo said modification.

No such luck on Windows 10. Where the hell are these things cached?

Edit: Oh, it's flagged to run as admin even when disabling its entry in Compatibility Administrator BEFORE copying the file in the virtual machine. That's nuts!

Edit2: I can reproduce the problem on Windows 8.1 as well. Maybe RunAsHighest shim is treated specially therefore disabling the entry doesn't disable it?

@lowenz

Could be something going on internally dependent on the sequence of calls the game makes. Is that a problem in practice? Isn't d3d11.dll the main one so as long as that works, everything's cool? I have no idea though.

[mirh]

Edit2: I can reproduce the problem on Windows 8.1 as well. Maybe RunAsHighest shim is treated specially therefore disabling the entry doesn't disable it?

Thanks for testing. I had always wondered if somewhere even W8 had been affected (cause afaik RTM wasn't).

[lowenz]

@lowenz

Could be something going on internally dependent on the sequence of calls the game makes. Is that a problem in practice? Isn't d3d11.dll the main one so as long as that works, everything's cool? I have no idea though.

Just my curiosity! It's.....strange, this sudden change in behaviour, and maybe it's due to ReShade 3.1 but maybe to Fall Creators Update.