[SOLVED] Programs suddenly crashing.

[doveman]

• System has been experiencing only user-mode app/service crashes, no deadlocks or BSODs. CORRECT
• Symptoms only occur on Win7 and on two separate Win7 installations. CORRECT
• Backup image of what is suspected to be prior to symptoms for Windows 7 showed up no symptoms for a couple days then symptoms resurfaced. PARTIALLY RESURFACED, ARMA2OA WON'T LOAD AGAIN BUT DCS WORLD IS STILL WORKING. I UNDERSTAND THAT ARMA2OA CAN ONLY USE A MAX OF 2GB BUT DCS WORLD IS 64-BIT AND CAN USE MUCH MORE, ALTHOUGH IN THE PAST WHEN I'VE MONITORED, IT DOESN'T.
• Symptoms do not occur on XP. CORRECT
• Memtest was conducted a number of times for several passes for all 4 sticks, no failures detected. ONE TIME, TWO PASSES OVERNIGHT
• Top 2 RAM modules have been removed, Memtest ran again. No failures detected. Symptoms still occur in userland. I DIDN'T RUN MEMTEST WITH ONLY TWO MODULES. AFTER REMOVING TWO DIDN'T HELP, I PUT THEM BACK AND THEN RAN MEMTEST.
• Prime95 on 45 minutes on Blend showed up ok. CORRECT

 

[doveman]

Would it be possible for you to retrieve for us a crashdump or two from these appfaults? When WerFault (the error message) appears saying the app has crashed, it will usually provide a link to the crashdump file. That crashdump file is temporary and often I've found it's deleted the moment WerFault is closed, so while the error message is still up direct yourself to that file and move it to a safe location then send to us for evaluation. Doing this for multiple crashing programs will allow us to detect any patterns between them that can help determine cause. You may also provide us with a full dump when the app crashes by keeping the error message open, then open up Task Manager (or Process Explorer, preferably) and right-click the app (not WerFault but the crashing app) and select Create Dump then Full Dump (for Process Explorer). It will be rather big so you may need to upload to 3rd-party site (make sure to zip first).

It may even be necessary to run Application Verifier on the faulting program. Set it up to point it to the application you want to test and save the settings, then open the app and let the app crash. It may end up providing more accurate details in the crashdump WerFault churns out than if done otherwise. You don't have to tweak the actual check settings, I believe, as the basic stuff seems enough for now. You can ignore the prompt it gives you for having the app run in a debugger at this time

I've uploaded the process explorer dump for ArmA2OA here: https://docs.google.com/file/d/0B1fDI89phEESZlpXVHRMNEFCcTg/edit?usp=sharing

It's 273MB. It was rather tricky to make it as whilst the error box is up I have no mouse cursor, so had to alt-tab to Process Explorer and then use the keyboard to navigate in that to create the dump. As soon as I tab to the error box and press Enter my mouse returns to normal. The error box is first a "looking for solutions" one and then changes to notify me that ArmA2OA has closed (in fact it doesn't close until I close the error box) but there was never an option to create a dump, so I had to use PE.

Let me know if you want me to run Application Verifier on it. I've tested loading Mediaportal, which was another program that couldn't load until I restored from the TI backup and that's fine, so at the moment the problem seems isolated to ArmA2OA.

 

[niemiro]

@niemiro:

Where are you getting the conclusion on the bitshift? I don't see Windows Update in his previous posts nor any hint to a bitshift. I may be overlooking something so please direct me. :)

It was just a couple in the registry in a thread from a little while ago: https://www.sysnative.com/forums/windows-update/3791-windows-update-not-working.html

They may not be bitshifts, they just looked sort of like it.

mdmusrgl.inf_31bf3856ad364e35_6®1.7600.16385_b2c1c88417dc71f1
mdmusrgl.inf_31bf3856ad364e35_6.1.7600.16385_b2c1c88417dc71f1

mdmusrf.inf_31bf3856ad364e35_6.1.7600.16385_c20²376b9c50961e
mdmusrf.inf_31bf3856ad364e35_6.1.7600.16385_c202376b9c50961e

Richard

 

[doveman]

I've restored the same True Image backup to my second Windows partition now and Arma2 launches fine using that but still crashes on loading in the first Windows, so I think it's reasonably safe to say it's not a hardware problem but I'll run memtest overnight anyway.

 

[doveman]

I noticed the error in Arma2OA's RPT refers to aticfx32.dll, which I assume is something to do with Crossfire, in which case it seems strange as I only have a single 6950 card.

Exception code: C0000005 ACCESS_VIOLATION at 004EA8A2
Allocator: D:\Games\ArmA 2 Operation Arrowhead\expansion\beta\dll\tbb4malloc_bi.dll
graphics:  D3D9, Device: AMD Radeon HD 6900 Series, Driver:aticfx32.dll 8.17.10.1132
resolution:  1920x1200x32

I ran dxdiag and noticed that next to Main Driver: it just says aticfx64.dll repeated over and over, which seems rather peculiar. It shows this in both 32-bit dxdiag and the 64-bit one.

 

[doveman]

Hmm, seems the dxdiag is normal as it looks the same on the working Windows.

I did two passes of memtest overnight, running with my usual overclock of 3.6Ghz@1.375v and NB 2400Mhz@1.3v and no errors there, so the RAM seems fine.

 

[Vir Gnarus]

Yes, I do see in the crashdump the TBB Game Allocator for Arma 2 performing the illegal handling of memory, but at this moment I'm having difficult determining exactly what address it was trying to refer too, and even if I did I won't be able to guarantee that I can find if the address is to legit memory or not (unless it's a completely buggered address like a null value), since this is a usermode crashdump so such information is inaccessible. I think this is where Application Verifier needs to come in. Sending the crashdumps produced by Werfault would also assist.

One thing that concerns me a good bit is the amount of overlapped modules present, mainly DirectX and net-based RPC modules. I'm not sure if this is supposed to happen or not, but part of me thinks no, it shouldn't. I wouldn't know the first thing on what's causing it, though.

At this moment in analyzing the dump I can provide names of 3rd-party drivers present in the faulting thread stacks that should hint to possible causes, but don't bet too much on em. I think we just hit this problem too late, which is why App Verifier would assist in catching it earlier.

• ATI's PowerXpress module (PowerXpress switches between intergrated and dedicated graphics)
• Remote RPC module (not 3rd party, but hints to network-based operations)
• DirectX's XINPUT module (for controller input; again, not 3rd party, but involved)
• AMD's Radeon DirectX Universal module (dated Jun 11, 2012)
• COMODO Security module (guard32.dll)

Again the more crashdumps the better.

 

[doveman]

Thanks for taking a look. I'll reproduce and upload the Werfault and Application Verifier dumps.

The only thing I can say about those drivers is that my motherboard doesn't have integrated graphics so PowerXpress doesn't seem to serve any purpose on my system.

The only other one I could take out of the equation is Comodo by uninstalling Comodo Firewall but that's installed in the working Windows so isn't likely to be causing the problem.

 

[doveman]

Perhaps it was because Application Verifier was running but ArmA2 crashed a lot earlier (I didn't even see the loading bar) this time.

The log from AV is here https://docs.google.com/file/d/0B1fDI89phEESa1RQOHdWNkJCMkU/edit?usp=sharing

and I also grabbed the WER files which are here: https://docs.google.com/file/d/0B1fDI89phEESSW5LOGQ1SkU1NFU/edit?usp=sharing

 

[doveman]

Ah, found the problem at last :)

It's a program called FreeTrackNoIR. I'd not run the installer but just copied the files into a folder, so I didn't suspect it could be messing with anything but it turns out it creates a registry key when run pointing to a DLL it uses and it was this that was causing ArmA to crash. Once I deleted that registry key, ArmA loads fine again.

So I think I'm good for now, thanks for all your help. Fingers crossed there's no other problems lurking but I haven't noticed anything else in the last day or two so it's looking good :)

 

[Vir Gnarus]

Thanks for the update. I had a strong feeling it was that application but it sounded like you were intent on using it so I disregarded it since it seemed crucial to you. Keep us aware of any further notices and mark this thread as solved at your discretion.

 

[doveman]

Just want to mention that FTNoIR is still in Alpha and the authors have already come up with a workaround to prevent it crashing ArmA. Didn't want anyone else who might stumble across this thread to think it's badly written software that they should avoid :)

 

[doveman]

OK, system seems to be fairly stable at the moment. Opera still crashes a lot but that seems to be happening for a lot of people so I'm using Iron for now and am going to try Opera 32-bit as that seems more stable than the 64-bit version.

The main problem I still have is that IE9 is extremely slow to open pages. The actual program launches normally but then takes ages to open the Home page and any subsequent pages, whilst Iron and Opera open them nice and quickly.

Whilst I don't use it much, it's handy for the occasional page that doesn't work properly in the other browsers and to let guests use in Sandboxie as a clean browser so it would be nice to fix this problem. I'm curious about what could be causing it anyway

I should probably start a new thread about this though, just wanted to update this thread with my current status.

 

[jcgriff2]

Try IE9 in Safemode w/ Networking -- see if same slowness occurs.

Also, reset IE9 - Reset Internet Explorer settings in Internet Explorer 9

 

[doveman]

Try IE9 in Safemode w/ Networking -- see if same slowness occurs.

Also, reset IE9 - Reset Internet Explorer settings in Internet Explorer 9

Thanks, resetting seems to have helped although I'm not sure as sometimes it seems to open instantly and sometimes still has trouble. I had to re-enable Classic Shell's Classic Explorer Bar add-on after resetting, so maybe that was/is causing some issues. I'll test in Safemode as you suggest but also try disabling the add-on again to see if it definitely makes a difference.