Hi.We're having some random access violation when runinng our application on Windows 2008 Server(fully updated). According to my understending of the madExcept logs, the errors are occurring in the madExcept's own code.Here are three logs of the errors: https://dl.dropboxusercontent.com/u/221 ... ordhcp.zip.

It's weird that you don't get a proper callstack for the main thread. That could be a bug in madExcept, but this is probably of no consequence for this specific problem.

The crash occurs when a thread is calling "IPHLPAPI.GetAdaptersAddresses()". The crash is occuring somewhere inside of the IPHelper dll. This is a system dll. Does your code call "GetAdaptersAddresses()" somewhere? Or maybe some of the third party components you're using? madExcept itself does not call this function.

The "madExcept.CallThreadProcSsafe" and "madExcept.UserWorkItemExceptFrame" items in the callstack have to be there. That's how madExcept is able to automatically catch exceptions in secondary threads for you. These callstack items do not in any way indicate that madExcept is causing the crashes.

I searched through all the project and it's components and none of them uses the GetAdaptersAddresses.The fact that there is no call stack for the main thread, is that we unchecked the "call stack of all running threads" option.

Well, I can't say from the bug report who's calling GetAdaptersAddresses and why. But somebody does, inside of your process. It could be an indirect call. Meaning some of your code (or 3rd party code, or some Delphi RTL/VCL unit) calls some other win32 API and that internally calls GetAdaptersAddresses. Maybe it's somehow related to that Soap Http stuff? GetAdaptersAddresses has something to do with network, IP etc... I don't know, just guessing around here...

I wish I could tell you more, but there isn't really any more information in the crash report for this specific problem...

we got the same AV but with the MainThread-Callstack. Seems that the application is shutting down. Maybe this helps to track down the problem.We assume that the problem has something todo with W2008 Server, maybe one should set the tsaware-flag?

Looks like the dhcpcsvc6.DLL might already be unloaded in the moment when "IpHlpApi.GetAdaptersAdresses()" internally tries to call "hdcpcsvc6.DhcpIsEnabled()". Or maybe not. Can't say because the bug report is incomplete (no module list). It's also possible that the dll is still loaded, but in the process of being unloaded or something.

That is extremely weird. Taking the disasm into account, the bugreport suggests that the 0x740f1xxx code page of dhcpcsvc6.dll was changed to "non executable" while a thread was still running through that code. Not sure how this can happen. I would say the most likely situation is that some other thread is trying to unload that dll while the crashing thread is still executing code in the dll. Or maybe some other thread has changed the page access rights of the dll for some reason (could be a bug in the code or something).

Hi,I get the same error. It is happening on a citrix terminal server environment. We are using MapiSendMail to open the default mail client. The customer has outlook. Outlook popups having all the data we provide in the code. But randomly, the application is crashing behind the outlook's new mail window. Madexcept is also failing to send us the report so i have paid a visit to customer and did some screen shots with the error and with the call stack. I've attached the files.Do you have any clue on why is happening? We get this error only on citrix and we are not able to reproduce it on our test/devel computers.

According to the bug report the crash occurs in a thread created by "mso.dll" which is a part of Microsoft Office. I suppose this could be the dll handling the MAPI transport from your process to MS Outlook. This is just a guess on my part, though. If I'm guessing correctly, the bug could be in "mso.dll". It might make sense to switch to a better mail sending method. E.g. SMTP or HTTP upload. You could also try updating MS Office with the latest service packs in the hope that this might fix the problem.

TS (and Citrix) are the classic case where a server version of Windows ends up hosting desktop applications and thuswhere you see this annoying issue.

Now in the above KB, Microsoft recommends exempting Outlook.exe from DEP to workaround the issue.However, when talking via MAPI to Outlook, the problematic non DEP-safe code will be running in *your* address space,thus you will need to exempt *your* processes exe from DEP checking or suffer these spurious AVs.

While searching on the internet about the issues on terminal server environments, i also found that is possible to make your application TS-aware by adding this flag: {$SetPEOptFlags IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE}I had no time to test this. Do you know anything about it? Will DEP consider the application safe if it was built with this flag?