Does FSUIPC use NTDLL.dll?

[YankeeFan]

Hi Pete,

Does FSUIPC use ntdll.dll directly or indirectly when writing data to an offset or in any other way? The reason I ask is it appears ever since I started writing to offsets 32FA and 3380 to send informational messages from my program to FS so that it appears in the ATIS text box (white text on green background) on screen, alot of users of my application are experiencing an Windows error message at random times. Such as "Active AirSource has encountered a problem and needs to close. We are sorry for the inconvenience." It refers to module ntdll.dll at offset 0006112b. Which I am not using in my application, however FSUIPC is an intregal part of my application and was wondering if you are using it.

Thanks for any assistance,

John McCormack

[Pete Dowson]

Does FSUIPC use ntdll.dll directly or indirectly when writing data to an offset or in any other way?

Pretty much everything uses NTDLL.DLL, as it is the support for many Windows APIs and probably many parts of Windows.

The reason I ask is it appears ever since I started writing to offsets 32FA and 3380 to send informational messages from my program to FS so that it appears in the ATIS text box (white text on green background) on screen, alot of users of my application are experiencing an Windows error message at random times. Such as "Active AirSource has encountered a problem and needs to close. We are sorry for the inconvenience." It refers to module ntdll.dll at offset 0006112b. Which I am not using in my application

You are pretty well certain to be using NTDLL, it is almost impossible to avoid. You might as well say "I am not using Windows".

If your process is crashing, which it is, then there is an error occurring in your process. If FS is crashing then that's another matter, but I'm afraid only you can debug your program.

Check that in your string or array handling for the strings you are trying to write you are not exceeding some bounds and overwriting something else in your program. You can easily create stack corruption which could be reported later in almost any of the depths of Windows.

Windows XP is very good at preventing errors in one process destroying another.

Regards,

Pete

[YankeeFan]

Thank you Pete for your suggestions. I've taken a close look and am following the guidelines set forth in the Programmers Guide for FSUIPC for those two offsets, so I guess I'm at a lost for moment. I will keep digging at and try some diff. things to see if I can isolete the possible cause further.

Thanks again for your suggestions and a fast reply!

[Pete Dowson]

I've taken a close look and am following the guidelines set forth in the Programmers Guide for FSUIPC for those two offsets, so I guess I'm at a lost for moment. I will keep digging at and try some diff. things to see if I can isolete the possible cause further.

There's no magic about those offsets compared with any others. I'm sure it is really nothing to do with those, though it may be to do with the code around your access to them.

If it is crashing in your program, which it is, you should be able to get a DrWatson dump and locate the last call to Windows (or more likely to a library routine) you did before the crash. If you can reproduce the problem then it should be easy enough, as you can use the Debugger which comes with the language compiler you are using. If you cannot reproduce it, then you'll need to add some diagnostics to your program -- I do this via my Log files.

Regards,

Pete

[YankeeFan]

Thanks again for the additional suggestions/tips. The strange thing is I've run my application in Debug mode where I can add breakpoint and check values at any line in my application, and I dont find any problems whats so ever. However, with over 100-200 users of my application their PC systems can be quite diff. including Flight Sim version 2000 to 2004, Windows OS 98/XP Home/XP Pro, FSUIPC versions from 2.9xxx to 3.202, even languages from English to Czech, so it has been a real challenge to say the least to try to troubleshoot. In my application whenever an error occurs it will write to an errlog.txt file, but when Windows jumps in and causes error messages it is a bit hard to trap those to include to the errlog.txt file.

I am just waiting for the day where it will become obvious whats happing.

Thanks again!

John McCormack

[Pete Dowson]

In my application whenever an error occurs it will write to an errlog.txt file, but when Windows jumps in and causes error messages it is a bit hard to trap those to include to the errlog.txt file.

Yes, to find errors like that you need to log things around the area you suspect, so that you can eventually narrow down the place, in your program, from which the Windows error is occurring. Unless your program is multi-threaded (which can be a real nightmare to debug, believe me!), this should be reasonably easy.

You can also write your own error trapper using standard Windows API calls. In recent versions of MSVC this is by using the __try{} and __except{} structures. They can trap access violations, et cetera.

I am just waiting for the day where it will become obvious whats happing.

I'm afraid things don't really work like that. You need to think through the possibilities and lay the traps, step by step, narrowing it down till you find the cause. This can involve sending different test versions out to your users (the ones experiencing the problem) so that they can return you the information, which you can thereby gradually piece together.

Regards,

Pete