Strange behaviour
Strange behaviour
A very simple application loads a very simple DLL at run-time. Both the app and DLL contain only madExcept code and Windows, Classes units. When I start the app it reports many strange resource leaks. If I just rename the executable file or move it to other folder it does not report anything. Can be the executable file cached somewhere. OS is Windows 10.
Re: Strange behaviour
That sounds extremely strange! I have no explanation right now. Recompiling doesn't change anything? What happens if you recompile and add an intentional leak. If you then rename the EXE, does it report only that one leak?
Re: Strange behaviour
No, if I recompile/rebuild the executable or DLL it does not change anything. If I rename EXE it reports no leaks at all. It looks like the leak reporting depends on the executable name.
Re: Strange behaviour
If you rename the EXE it reports no leaks even if there are some leaks? Not sure why that would happen.
Can you reproduce any of this with a brand new test project?
Can you reproduce any of this with a brand new test project?
Re: Strange behaviour
Finally, I've found the source of the problem.
The following registry node
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers
contains a key "myapp.exe" with the value "$~ IgnoreFreeLibrary<mydll.dll>"
I don't know that added this registry value.
The following registry node
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers
contains a key "myapp.exe" with the value "$~ IgnoreFreeLibrary<mydll.dll>"
I don't know that added this registry value.
Re: Strange behaviour
I've never even heard of that registry key yet.
So all problems solved?
So all problems solved?
Re: Strange behaviour
Yes, the problem is solved. I've just deleted this registry value. It seems that the compatibility assistant is very aggressive on Windows 10 now.
Re: Strange behaviour
In continue of this problem. I've found when Win10 adds this registry node. I've enabled madExcept in a DLL
When I close the application the following leak report appears. I close the leak report and do not save it. After this Windows shows a dialog and reports that the problem has been found in this program and it will be closed. Then the registry node mentioned before appears in AppCompatFlags\Layers
allocation number: 114986
program up time: 1,99 s
type: Window Handle
handle: $1e3132
class name: madToolsMsgHandlerWindow$1374$235b1804
visible: -
rect: 0,0,0,0
main thread ($1374):
671d7118 madExcept32.dll madExceptDbg 6115 CreateWindowExACallback
235a9413 expressions.dll Windows 30923 CreateWindowExA
235b19bd expressions.dll madTools MsgHandlerWindow
235b1b39 expressions.dll madTools AddMsgHandler_
235b1cc8 expressions.dll madTools AddMsgHandler
235db211 expressions.dll madExcept InitFireHandlers
23605593 expressions.dll madExcept Init
23605f83 expressions.dll madExcept initialization
235a4fcc expressions.dll System InitUnits
235a50bc expressions.dll System @StartLib
77e02040 ntdll.dll LdrLoadDll
004bc06a app.exe madCodeHook LdrLoadDllCallbackProc
75807791 KERNELBASE.dll LoadLibraryExA
75809fed KERNELBASE.dll LoadLibraryA
006e046c app.exe Main 1026 TfrmMain.LoadModuleAsync
When I close the application the following leak report appears. I close the leak report and do not save it. After this Windows shows a dialog and reports that the problem has been found in this program and it will be closed. Then the registry node mentioned before appears in AppCompatFlags\Layers
allocation number: 114986
program up time: 1,99 s
type: Window Handle
handle: $1e3132
class name: madToolsMsgHandlerWindow$1374$235b1804
visible: -
rect: 0,0,0,0
main thread ($1374):
671d7118 madExcept32.dll madExceptDbg 6115 CreateWindowExACallback
235a9413 expressions.dll Windows 30923 CreateWindowExA
235b19bd expressions.dll madTools MsgHandlerWindow
235b1b39 expressions.dll madTools AddMsgHandler_
235b1cc8 expressions.dll madTools AddMsgHandler
235db211 expressions.dll madExcept InitFireHandlers
23605593 expressions.dll madExcept Init
23605f83 expressions.dll madExcept initialization
235a4fcc expressions.dll System InitUnits
235a50bc expressions.dll System @StartLib
77e02040 ntdll.dll LdrLoadDll
004bc06a app.exe madCodeHook LdrLoadDllCallbackProc
75807791 KERNELBASE.dll LoadLibraryExA
75809fed KERNELBASE.dll LoadLibraryA
006e046c app.exe Main 1026 TfrmMain.LoadModuleAsync
- Attachments
-
- screenshot1.png (36.96 KiB) Viewed 8701 times
Re: Strange behaviour
It seems that the "Report leaks" options still work in the DLL project even if the "Link in madExcept settings" option is disabled (the "LeakChecking" conditional directive exists in the project settings).
Re: Strange behaviour
I'm not sure whether there's a question hidden somewhere in your last 2 comments?
My best guess is that there's a crash somewhere in your application (exe or dll) and that Windows 10 thinks it can work around it by activating some weird compatability setting. You could check whether disabling leak reporting "fixes" that issue.
My best guess is that there's a crash somewhere in your application (exe or dll) and that Windows 10 thinks it can work around it by activating some weird compatability setting. You could check whether disabling leak reporting "fixes" that issue.
Re: Strange behaviour
Question 1: should madExcept report leaks with the settings showed on the attached screenshot? Currently, it does, but I can't change the state of the "Report leaks" checkbox. It is not the bug, but this behavior is unexpected, because the settings are not linked and the "Report leaks" checkbox is disabled.
Question 2: why Windows does not report about problems in my software if I disable the "Report leaks" option or remove madExcept32.dll from the program folder.
Question 2: why Windows does not report about problems in my software if I disable the "Report leaks" option or remove madExcept32.dll from the program folder.
Re: Strange behaviour
Sorry for the very late reply.
I've just tried to reproduce the problem here. But I can't. Created a test project with an EXE and a DLL, both have madExcept enabled, but leak reporting is only active in the EXE. And it works as intended. Leaks are reported if they occur in the EXE, but not if the DLL produces them. Not sure what went wrong in your case. Maybe leak reporting wasn't fully disabled in the DLL for some reason. One thing you could do is check the resource "RCData\TMADEXCEPT" in your DLL file. There's a "ReportLeaks = true/false" value in that resource. Does it say "true" or "false"?
I've just tried to reproduce the problem here. But I can't. Created a test project with an EXE and a DLL, both have madExcept enabled, but leak reporting is only active in the EXE. And it works as intended. Leaks are reported if they occur in the EXE, but not if the DLL produces them. Not sure what went wrong in your case. Maybe leak reporting wasn't fully disabled in the DLL for some reason. One thing you could do is check the resource "RCData\TMADEXCEPT" in your DLL file. There's a "ReportLeaks = true/false" value in that resource. Does it say "true" or "false"?