Global Atom Table - '-D4%' prefixed atoms

Robert Massart 6

Trying to get an answser to the following:

Here's what we see if we batch convert text document through word over a 1 hour period, converting 10 in parallel at a time on an 8 core system:

Atom Monitor 1.4

Pattern: ControlOfs[0-9A-Z!?/+-]+ Counts: 2
Pattern: ConIME.[A-Za-z.]+ Counts: 0
Pattern: {[0-9A-Z-]+} Counts: 14
Pattern: ^T[A-Za-z_-]+ Counts: 54
Pattern: AtomTestXXXX Counts: 0
Pattern: AtomTestBXXXX[0-9A-Z!?/+-]+ Counts: 0
Pattern: RWMTestXXXX Counts: 0
Pattern: RWMTestBXXXX[0-9A-Z!?/+-]+ Counts: 0
Pattern: MyFormTestXXXX Counts: 0
Pattern: TQRE[A-Za-z]+ Counts: 0
Pattern: commdlg_help Counts: 1
Pattern: commdlg_FindReplace Counts: 1
Pattern: WndProcPtr[0-9A-Z!?/+-]+ Counts: 1
Pattern: UXTHEME.DLL Counts: 0
Pattern: OPDESTROYCLOSEBTN Counts: 0
Pattern: BDSUnthemedDesigner Counts: 0
Pattern: TaskbarCreated Counts: 0
Pattern: MSWHEEL_ROLLMSG Counts: 1
Pattern: SHELLHOOK Counts: 1
Pattern: Delphi[0-9A-Z!?/*+-]+ Counts: 1

Pattern: -%D4#!.* Counts: 6655

Total Atoms (Global Atom Table): 6772

Total Atoms (RWM Atom Table): 641

Total Atoms: 7413

Some lines from the Atom List:

C069 = -%D4#!
``Y@"

`@D%

``  --GlobalAtom
C06A = -%D4#!

``35!

`@D%

--GlobalAtom C06B = -%D4#!3O$

`@D%

``  --GlobalAtom
C06C = -%D4#!

``2@!

`@D%

--GlobalAtom C06D = -%D4#!!`"

`@D%

``  --GlobalAtom
C06E = -%D4#!

``;M"

`@D%

--GlobalAtom C06F = -%D4#!6`!

`@D%

``  --GlobalAtom

CPU is being stressed so again thinking is just not enough time for actual cleanup of the Atom Table to occur.   

Stopping the worker threads does allow these Atoms to eventually get cleaned up but it takes a really long time.

MS, how do we prevent this backup of deletions from happening?



originally posted on WDK but I think it might be more appropriate here. [ms-word-foreign-language-editions-splwow64-global-atoms-starting-with-d4][1]


  [1]: https://social.msdn.microsoft.com/Forums/windowshardware/en-US/d0ee44d3-ea96-4a1c-8036-b9f36d29107b/ms-word-foreign-language-editions-splwow64-global-atoms-starting-with-d4?forum=wdk

Joy Qiao 4,896 Reputation points Microsoft Employee

2020-09-29T03:46:41.687+00:00

Hi,

What's your system version?

In order to help you better find the engineer who fit for your problem, can you tell us what exactly you have done? Can you take photos or upload pictures related with "get a global atom leak." Or would you make a description for global atom leak?

By the way, "print global atoms" do you mean print out on paper with printer or print out in command with script?

I noticed you post your thread on driver development forum, do you mean you aim to develop a specific driver?

Thank you for your reply.

Bests,
Viorel 117.2K Reputation points

2020-09-29T06:00:57.993+00:00

Did you confirm that these atoms exist and are not caused by a defect of monitoring tool?
Robert Massart 6 Reputation points

2020-09-29T12:21:18.073+00:00

The operation systems are all : Windows 7 to Windows 2019. It makes no difference they all exhibit this behavior. I been focused on Windows 2016 and Windows 8.1 but the OS version can be any.

Attached is a Word2003 xml formatted document with pictures .

29075-globalatomleakorpendingdeletionissue.xml
Robert Massart 6 Reputation points

2020-09-29T12:23:08.79+00:00

Yes the atom monitor is reporting the correct information. You can see attached for more info what I'm seeing:

29134-globalatomleakorpendingdeletionissue.xml
Joy Qiao 4,896 Reputation points Microsoft Employee

2020-09-30T02:04:07.197+00:00

Hi,

Very appreciate for your information, it's detailed and clearly.
I noticed you said "Our system is about automating the conversion of documents to TIFF or PDF and during this process we use Word to print documents to a format we use to generate TIFFs or PDF files."

Do you mean you are developing a system by your company?
Does the system a UWP type, Win32 based or WPF(Windows Presentation Foundation)?

Bests,

============================================

If the Answer is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
Robert Massart 6 Reputation points

2020-09-30T11:26:46.77+00:00

Yes we develop and sell this conversion solution. It's a combo of .NET and Win32. But this is really not the issue so I don't want to continue this thread of conversation.

What were trying to understand is why these '%D4#!' prefixed gobal atoms are consuming up the atom table when the load on the system is heavy. We find that even if the CPU (8 cores) average 80%+ the number of these entries grows so that over the first 1 you have approximately 1000+ of these entries and continues to grow. If you increase the load to 90%+ the growth is an even greater rate. We find the load needs to be about 60-70% in order for the these entries to to grow, the count stays around 100.

Who in MS is responsible for the Global Atom Table implementation and can they please explain what we are observing.
Robert Massart 6 Reputation points

2020-10-01T12:27:07.963+00:00

Sorry the second paragraph was not clearly written. Let me rewrite this:

What were trying to understand is why these '%D4#!' prefixed gobal atoms are consuming up the atom table when the load on the system is heavy. We find that even if the CPU (8 cores) average CPU usage 80%-85% the number of these entries grows so that over the first hour you have approximately 1000+ of these entries and these entries will come and go but you have a average count of 5000 entries. If you increase the load to 90%+ the growth is an even greater rater and never stops growing so eventually processes can't be created and splwow64 will crash, etc...

Need CPU Usage 60-70% in order for the these entries to not grow, the count to stay around between 100-200. atoms to come and go.

If you do have a high count after hour of CPU Usage over 80% you can stop the processing and bring the CPU back to 40% usage and you will see a slow cleanup of these atoms over time.
Robert Massart 6 Reputation points

2020-10-13T16:44:39.29+00:00

I did confirm Global Atom table has the -%D4#! entries after global atoms get deleted by any Windows program. These entries get cleaned up at a rate of approximately 10-7 every 10 seconds when CPU is not under any load. These entries of course build up under load because the cleanup rate is way to slow. At 1 per second they get actually removed from the Global Atom table but applications are creating and destroying them at a much higher rate (several per second). Hence, global atom table fills up over time with these entries (pending deletion/cleanup).

I NEED a Microsoft Internal OS Engineer to explain this finding and what are we suppose make this work better.

Please MS, can you send this to the appropriate OS department. Thanks
Robert Massart 6 Reputation points

2020-10-13T17:25:42.78+00:00

32063-globalatomtableviewercpp.txt

This is source code for how to dump the global atom table using WIN32 APIs.

Thought this might help.
Robert Massart 6 Reputation points

2020-10-13T18:16:39.567+00:00

Also if you use NtQueryInformationAtom BasicInformation you will find the '-%D4#!' atoms have a usage count of 1 and Flags = 0x02. So given this information I called :
if (info.UsageCount == 1 && info.Flags == 0x02 ) {
GlobalDeleteAtom(atom);
}

And the enter gets deleted correctly right away.

There is no documentation on the Flags for NtQueryInformationAtom so I don't know what 0x02 means. Does anyone know the meaning of the flags?

So I have determine at least I can create a process to force cleanup of these entries in real-time but it's still a mystery as to what these '-%D4#!' entries are and why they occur at all and who is cleaning them up as a very low priority task.

All I know is they are part of the Windows OS system (maybe the print queue ???)

1 answer

Drake Wu - MSFT 991 Reputation points

2020-10-02T03:17:14.18+00:00

Hi @Robert Massart It seems that your program is leaking the global atom table. The program should use GlobalDeleteAtom to reduce its reference count when it no longer needs to use local atoms. If the atom's reference count reaches zero, GlobalDeleteAtom removes the string associated with the atom from the global atom table.

According to this document: Atom Table Size:

If there is concern about the application causing user atom table issues, you can investigate the root cause by connecting the kernel debugger and breaking into the process on calls to UserAddAtomEx (bae1 win32kbase!UserAddAtomEx /p <eprocess> "kc10;g"). Look for user32! on the callstack to see which API is being called. The methodology is similar to the global atom table issue detection explained in Identifying Global Atom Table Leaks. Another way to dump the contents of the user atom table is by calling GetClipboardFormatName over the range of possible atoms from 0xC000 to 0xFFFF. If the total atom count steadily goes up while the application is running or does not return to baseline when the app is closed, there is a problem.

If the answer is helpful, please click "Accept Answer" and upvote it.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
Please sign in to rate this answer.
Robert Massart 6 Reputation points

2020-10-05T11:10:31.803+00:00

Sorry, but your talking about all programs on run on windows leaking global atoms. If you read anything I wrote you will realize it's not one specific program. All windows applications exhibit this behaviour when the CPU is under load. I just happen to be using office apps Word,Excel, etc... but it not limited to them. So DEFINITELY not global atoms leaking. It must have something to do with how Global Atom table is handle with Atoms are deleted.

But without access to how this process works exactly I can not verify this. I can only say what we are observing.

Drake Wu - MSFT 991 Reputation points

2020-10-13T00:54:01.917+00:00

This seems to be related to the performance of the computer, ,maybe you could submit this issue to the Feedback Hub.

Robert Massart 6 Reputation points

2020-10-15T18:43:15.5+00:00

Okay, I think the '-%D4#!' atoms are SHITEMID structures

This is based off the fact the call stack in the screen shot below calling ILCloneFirst which ends up calling GlobaGetlAtomName and result is a '-%D4#!' atom.

https://video2.skills-academy.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-ilclonefirst

So the culprit is SHELL32 somehow????

Come on Microsoft. It's time to figure out what is going on.

Fei Xue - MSFT 1,111 Reputation points

2020-10-16T02:50:32.69+00:00

Please report this problem using Feedback Hub. If you also got this issue when developing an application using Windows SDK and it is urgent, please create an incident from Windows developer support-Contact Us so that our support engineer can work with you to fix it as soon as possible. And if the support engineer determines that the issue is the result of a bug the service request will be a no-charge case and you won't be charged.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Global Atom Table - '-D4%' prefixed atoms

Pattern: -%D4#!.* Counts: 6655

Total Atoms (RWM Atom Table): 641

1 answer

Your answer