I have found in the file madExcept.pas there is a difference in execution:
Line 19452 the pointer
is nil in the problematic execution and non-nil in the OK execution
Hopefully this will help
These should all be non-nil. According to the "madExceptWizard.txt" file you uploaded, these variables should all have been initialized correctly (to non-nil values) by madExceptPatch.exe.
1) Maybe when using Z:\, the YourProject.map file can't be created/updated correctly by the linker, so madExcept uses an old one?
2) Maybe when using Z:\, some anti-virus or similar software blocks some of the modifications madExcept does?
3) Maybe when using Z:\, the VM network logic somehow loses some of the modifications madExcept does?
None of that makes a lot of sense to me. But looking at the "madExceptWizard.txt" file, the variable "madExcept.Forms_TApplication_HandleException" was properly initialized with a non-"nil" value. So either the initialization was done to a wrong EXE file offset, which could happen if the map file wasn't correct. Or alternatively, the initialization was done, but somehow got lost by the file system or network handler, or blocked by an anti-virus software or something.
No other ideas right now, sadly...
I have set a breakpoint all lines where the pointer "Forms_TApplication_HandleException" is assigned.
The very first time the code hits a breakpoint is
At this point the pointer already got a value on the good compilation, and nil at the bad compilation.
I do not find the code where it was assigned - despite the variable was initiated to nil
Are there any other source files where this pointer is assigned?
It will unfortunately not be possible for me to change generally to UNC - and we also do not know the root cause for the difference
Or in short: madExceptPatch.exe "hacks" your EXE file by modifying the EXE file bytes on harddisk to initialize Forms_TApplication_HandleException. And according to the "madExceptWizard.txt" log you uploaded, it succeeded. So Forms_TApplication_HandleException should not be nil. Which is why I think it's like to problems 1), 2) or 3) in my previous comment.
(but root cause was not found)
The Z:\ drive was defined as "\\vmware-host\"
We do not know why this should pose a problem.
But by mapping the network drive as "\\ITQ-HP2\..." to a new driveletter it works.
In my investigation I did as follows:
- Delete the .map file just to be sure there was no old .map file
- temporarily turn off the realtime scanning from my McAfee antivirus
None of those tests worked.
So the conclusion is your proposal 3)
We can close the issue (but on long term it could be interesting to know why the mapped "\\vmware-host\" brings problem)
VMWare likely does this for security reasons. Try clicking on your VM and perform the following:
"Edit Virtual Machine Settings" -> click "Options" tab to the right of "Hardware" tab and navigate down to "Shared Folders"
You should see some settings there. Can't say if that would make a difference or not but I've run into a similar issue in the
past, just can't recall exactly what I did at the time to remedy it
I couldn't find any settings on my VM that could - intuitively - change the issue.
I do not consider it as a critical issue as long the alternative works
- Fileshare property
- Madshi_5.PNG (22.44 KiB) Viewed 3019 times
- Property of the individual shared folders
- Madshi_4.PNG (55.33 KiB) Viewed 3019 times