MAAM_TBM.gau

[WarHorse47]

Hi Peter.

I'm running FSUIPC 3.934 in FS9. From what I've read in the MAAM Support Forum and tested myself, there seems to be a conflict between the MAAM_TBM.gau file and FSUIPC.

Here is what happens. The experiences may be different between users and their setups, but with a normal install with FSUIPC, whenever someone tries to load the aircraft or change models they experience a CTD. The only way the aleviate the problem is to remove FSUIPC.dll from the modules folder and restart FS9. I tested this earlier this evening with FSUIPC version 3.81 and version 3.93 and sure enough the solution works.

Are you aware of this problem, and would you have any suggestions on what settings I might change on my FSUIPC.ini that might help me identify the conflict or even eliminate it?

Thanks in advance.

--WH

[Pete Dowson]

I'm running FSUIPC 3.934 in FS9. From what I've read in the MAAM Support Forum and tested myself, there seems to be a conflict between the MAAM_TBM.gau file and FSUIPC.

Here is what happens. The experiences may be different between users and their setups, but with a normal install with FSUIPC, whenever someone tries to load the aircraft or change models they experience a CTD. The only way the aleviate the problem is to remove FSUIPC.dll from the modules folder and restart FS9.

And does the Gauge still work fully without FSUIPC? Because the only way I can think of there being a problem is if the gauge is using FSUIPC and has maybe requested something which doesn't have an instantaneous response, and when the response arrives the Gauge has been removed from the system by an aircraft change.

Are you aware of this problem

No. Yours is the first report. I assume this MAAM_TBM.Gau file is new? What does it do?

and would you have any suggestions on what settings I might change on my FSUIPC.ini that might help me identify the conflict or even eliminate it?

No idea without any more information. Is there any problem noted in the FSUIPC.LOG file at all? Is the CTD a crash with no error message at all, nothing from Windows saying FS has crashed?

Is this Gauge freeware? If it can be added to any aircraft, and is freely available, I could test it here to see what is going on.

Regards

Pete

[Pete Dowson]

... whenever someone tries to load the aircraft or change models they experience a CTD.

I briefly looked at the AVSIM thread on this subject, and I think the term "CTD" is incorrect in a strict sense. By "CTD" we mean "crash to desktop" -- i.e. nothing to see, just the desktop. No error message, nothing, no helpful information at all. It used to be one of the most frequent crash types in FS9 before the 9.1 update came out, which seemed to fix most of them.

According to reports on the AVSIM thread, and I quote one:

When I went to try & load the Avenger I got a CTD w/the ModName maam_tbm.gau

it appears that this isn't a real CTD but a more understandable crash which Windows has detected and provided details for -- in this case actually identifying the villain as "maam_tbm.gau".

Since the crash is actually occurring inside that Gauge, not in any code of mine, there is really no way I am likely to be able to fix it. Just because it seems to only occur when FSUIPC is also loaded is not any indication that FSUIPC is contributing in any way other that by occupying some memory (hence making the memory patterns different) and possibly changing the timing of events slightly. It is pointing to a bug inside that gauge, such as using an uninitialised variable value, which will crash when the memory supposedly containing the variable has some sort of data left in it but not when other data is there. This is the most common types of intermittent bug, but if it is as reproducible as you say it should be easy to find with the normal Microsoft debugger and a debug copy of the gauge and its source.

I therefore recommend that you strongly appeal to the support section of the folks who make and sell this aircraft to get them to debug the code and fix the error.

I would certainly try to help in this further if the aircraft were freeware, or if the makers decided to send me a copy to test for them, but I am not prepared to purchase an aircraft I don't want in order to find a bug in their code. Sorry.

Regards

Pete

[WarHorse47]

Hi, Pete.

Thanks for the response. Thought I would provide a little more background.

The MAAM TBM has been out since about June 2008. When it was first released some of us reported CTDs related to the MAAM_TBM.gau. I did some minor beta testing with various versions of the gauge and some tweaking on the panel.cfg file to a point where the aircraft loading and model switching was quite stable. At that time I was running an earlier, registered version of FSUIPC.

IN the thread you referenced at SOH, I decided to see if I was having similar problems to other users. The bottom line is that any flight I create with any model of the TBM does not want to load unless I remove FSUIPC completely from the module folder. And as I mentioned this occured under FSUIPC version 3.81 and 3.934. So, simply stated, if I wish to fly this payware aircraft I have to disable FSUIPC.

I had made an educated guess that there might be a memory conflict as the module loads before the gauge. But I'm no expert and reading the detailed error message. I just know that it points to the gauge. Others have reported a solution with uninstalling various addon scenery, but doesn't lend itself to a final solution.

The MAAM Support forum suggests that the vendor is also looking for a common cause or conflict that is causing the problem. With so many users with differing setups, that is like looking for a needle in the haystack.

In reviewing the FSUIPC advanced user instructions, the modules appears to have a lot of settings and features. My inquiry was to ask if there might be some setting I could use to better define the conflict and report back to the vendor.

Anyways, if I learn anything new I'll pass it on.

Thanks

--WH

[Pete Dowson]

I had made an educated guess that there might be a memory conflict as the module loads before the gauge. But I'm no expert and reading the detailed error message. I just know that it points to the gauge.

The details provided in those error reports not only include the module name, but also the error tyoe (an 8-digit hexadecimal number) and also the actual address within the module at which the error occurred. This latter information is actually often extremely useful as it can pinpoint the exact place in the code experiencing the problem. But of course you have to have the source.

The MAAM Support forum suggests that the vendor is also looking for a common cause or conflict that is causing the problem. With so many users with differing setups, that is like looking for a needle in the haystack.

But if it can be reproduced so successfully, as you are saying, there should be no problem for the vendor to also reproduce it and therefore diagnose and fix it. The problems which are really difficult are those which simply don't occur except in very specific, though unidentifiable, circumstances. This doesn't appear to be the case from what you are saying.

In reviewing the FSUIPC advanced user instructions, the modules appears to have a lot of settings and features. My inquiry was to ask if there might be some setting I could use to better define the conflict and report back to the vendor.

For an unregistered installation of FSUIPC, none of those settings would have any affect on anything not using FSUIPC (which I must assume applied to this aircraft, else you wouldn't be able to use it without FSUIPC). There really isn't anything you can experiment with -- further information on the problem is needed first in any case.

Regards

Pete

[WarHorse47]

For an unregistered installation of FSUIPC, none of those settings would have any affect on anything not using FSUIPC (which I must assume applied to this aircraft, else you wouldn't be able to use it without FSUIPC). There really isn't anything you can experiment with -- further information on the problem is needed first in any case.

Mine is registered. I'll post anything more I uncover.

Thanks.

--WH