I have an odd issue on win7. Arma sometimes opens a process, but doesn't open it's window. Instead, it captures my mouse in a box about the ssize of a desktop icon, and seemingly responds to key input - that is, I can press esc to close it. Usually fixes itself after opening it a second time.
I have a hunch that arma doesn't pick up handles properly, and it happens across the board, with all versions.
Hrmm
Re: Hrmm
Would not be of much use for OS interaction troubles anyway. Most of it is handled by SDL before we even get a chance to record it, and the bits that do make it through need to be ignored or the recording would not play back.Jip wrote: catch it with a debug recording it didn't happen.
-
delinquent
- Match Winner
- Posts: 773
- Joined: Sat Jul 07, 2012 3:07 am
Re: Hrmm
Definitely an sdl bug then? It sounds to me like SDL was designed for winXP and down, but win7 applies handles much differently. Oddly enough, the same error happens under win8, but I believe that's down to the kernel itself.
I had a look at processes and other related crap, what confuses me is the double set of rules:
Using task manager, one can apply a contingency to a process, determining what priority and what affinity is given to the process.
Upon further inspection, there is a second set of rules that is governed by "/ad" which I assume is an abbreviation for administrator. These rules usually copy the user defined parameters, but have the permissions and ability to change. These rules also act on a hierarchy, which take precedence over user specific options.
Above "/ad" is "trustedinstaller", which can take further action by modifying the options imposed by "/ad". This governor, however, has no abilities of its own, which renders it useless unless it needs to change any lower values.
Using tscmana, and setting capture to 5ms, I can see that "explorer.exe" has occasional but frequent "blips" where its overall cpu usage jumps to over 80%. As this process is on a parallel permission level with trustedinstaller (Not the GUI, the backend), it has the ability to prevent programs from opening, disallow certain features and various other tasks.
My conclusion:
This explains a number of things. First: It is possibly the reason why the Aero theme is disabled for certain programs to function.
Second: It would explain why it seemingly is allowed to stop responding to user input, whilst not becoming a process that is "not responding".
Third: Since this error has occurred today with other SDL apps, and seeing as I've been running a few things, it is quite possible that opening a process/program at the same time as explorer.exe completing a high-usage cycle causes the program to function abnormally, due to it being denied adequate abilities/affinity/permissions/priorities. Perhaps some SDL functions are time and/or function dependent.
Now that I'm really getting into the guts of windows, I'm starting to realise how messy it has become.
I had a look at processes and other related crap, what confuses me is the double set of rules:
Using task manager, one can apply a contingency to a process, determining what priority and what affinity is given to the process.
Upon further inspection, there is a second set of rules that is governed by "/ad" which I assume is an abbreviation for administrator. These rules usually copy the user defined parameters, but have the permissions and ability to change. These rules also act on a hierarchy, which take precedence over user specific options.
Above "/ad" is "trustedinstaller", which can take further action by modifying the options imposed by "/ad". This governor, however, has no abilities of its own, which renders it useless unless it needs to change any lower values.
Using tscmana, and setting capture to 5ms, I can see that "explorer.exe" has occasional but frequent "blips" where its overall cpu usage jumps to over 80%. As this process is on a parallel permission level with trustedinstaller (Not the GUI, the backend), it has the ability to prevent programs from opening, disallow certain features and various other tasks.
My conclusion:
This explains a number of things. First: It is possibly the reason why the Aero theme is disabled for certain programs to function.
Second: It would explain why it seemingly is allowed to stop responding to user input, whilst not becoming a process that is "not responding".
Third: Since this error has occurred today with other SDL apps, and seeing as I've been running a few things, it is quite possible that opening a process/program at the same time as explorer.exe completing a high-usage cycle causes the program to function abnormally, due to it being denied adequate abilities/affinity/permissions/priorities. Perhaps some SDL functions are time and/or function dependent.
Now that I'm really getting into the guts of windows, I'm starting to realise how messy it has become.