http://bugs.winehq.org/show_bug.cgi?id=18640 --- Comment #3 from Anastasius Focht <focht(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.