http://bugs.winehq.org/show_bug.cgi?id=18640
--- Comment #3 from Anastasius Focht focht@gmx.net 2009-05-27 17:49:14 --- Hello,
regarding the missing stubs from the posting in mailing list:
--- snip --- gdi32.GdiEntry13 kernel32.WerRegisterMemoryBlock ntdll.NtSecureConnectPort ntdll.RtlEnumerateGenericTableWithoutSplaying ntdll.RtlIsGenericTableEmpty --- snip ---
gdi32.GdiEntry13 -> filed as bug 18638 ntdll.NtSecureConnectPort -> filed as bug 18639
kernel32.WerRegisterMemoryBlock:
http://msdn.microsoft.com/en-us/library/bb513620.aspx
--- quote MSDN --- If you use this function to register a memory block, the operating system will add the memory block information to the dump file at the time of the crash or hang. --- quote MSDN ---
Looking at trace log and comparing the addresses passed into RtlCaptureStackBackTrace() and WerRegisterMemoryBlock() stub in case .NET frameworks encounters error, the only purpose seems to ensure the captured stackframes will be part of the dump (same memory area). Because Wine doesn't provide RtlCaptureStackBackTrace() as of now, WerRegisterMemoryBlock() isn't needed. Failure to GetProcAddress() seems harmless. But you might of course send a stub if you like.
From testing with stubs, RtlIsGenericTableEmpty() is only needed if
RtlEnumerateGenericTableWithoutSplaying() really returns useful data (!NULL).
You could open another bug for that so it can be discussed further. Actually it could be quite possible that earlier render thread problem stem from the fact that current RtlInitializeGenericTable() is a stub and RtlEnumerateGenericTableWithoutSplaying() becoming a stub.
Regards