Re: D3D8 caps - wined3d
Hi, +/* Optimization */ +BOOLmodelview_valid; +BOOLproj_valid; +BOOLview_ident; +BOOLlast_was_rhw; +GLenum tracking_parm; ... Are you sure that this is the latest version of IWineD3DDeviceImpl? I think my patch which added a viewport_changed member here was applied to CVS. I don't have CVS access right now, but I think that the structure you added is out of date. pgpOQatfQaGCd.pgp Description: PGP signature
Re: gdi32: Fallback to StretchDIBits if the driver doesn't support BitBlt
Huw D M Davies [EMAIL PROTECTED] writes:
+if ((dcSrc = DC_GetDCUpdate( hdcSrc )))
+{
+dcDst = DC_GetDCPtr( hdcDst );
+TRACE(hdcSrc=%p %d,%d - hdcDest=%p %d,%d %dx%d rop=%06lx\n,
+ hdcSrc, xSrc, ySrc, hdcDst, xDst, yDst, width, height,
rop);
+
ret = dcDst-funcs-pBitBlt( dcDst-physDev, xDst, yDst, width,
height,
dcSrc ? dcSrc-physDev : NULL,
xSrc, ySrc, rop );
This is wrong, dcSrc doesn't always need to be valid for BitBlt.
--
Alexandre Julliard
[EMAIL PROTECTED]
explorer.exe is a child of new process
Hi, with current git/cvs I can see that there is now a new explorer.exe process running when I start process explorer. What is strange though, is that explorer.exe is a child of procexp.exe. Is this supposed to be like that? Cheers, Paul.
Re: Cross-Machine COM-Calls under Wine... (RePost from wine.user)
I assume you mean cross-process COM calls? No, no it works cross-machine. We've designed our own binary protocol (Variant-ParamArray-Serialization + support for IPersistStream regarding Object-Transport + ZLib-based Compression + built-in Strong-Encryption + MITM-secured Diffie-Hellman-Auth.). It has its own Server-Part, uses only one Port (where DCOM needs a complete Port-Range), it has a runtime- adjustable ThreadPool, it is working completely independent of DCOM and - most important - of the Windows-Registry. We've developed this some years ago, because we were annoyed by the DCOM-Config-Orgies and the Dll-Hell regarding correct Proxy/Stub- Interface-Registrations, the difficulties, to change COM-Binaries whilst continous operation - all those problems - gone since we implemented our own RPC-Server. If you have an XP- or W2K-VM somewhere, there's no setup needed, to test our Download (VB6-Runtime and ADO are then already present). Just copy the Server- and Client-Folders, start the appropriated Apps and play around, to get an idea of the whole thing (needs 5 minutes). The D-part of DCOM is not currently supported. I know, but as said, we don't need it. So Wine has ca. 3 times the Call-Overhead, regarding Object- Instantiation and Method-Invoking-By-Name... This is expected and it is on my todo list to fix this... Good to know... :-) 1. Running as Service... No. It doesn't really make sense at the moment. We don't recommend that Wine be run as root and we don't support impersonating other Unix users that would be necessary to maintain security in this environment. Ok, no big problem. 2. Win-Authentication and -Impersonation (LogonUser- and ImpersonateLoggedOnUser-APIs ... The probably both do nothing. Since you shouldn't be running as root, then this isn't a problem. Ok, no big problem under Linux, but the MS-SQLServer for example, supports (besides DB-Internal Security-Accounts) Win-Based-Security (Tables/Views/etc., wich are secured using Win-Auth.) and this feature is often used by MSSQL-Admins - that's why impersonation is (among other things) important under Windows inside the Pre-DB-Layer. But someone who decides, to do COM-Hosting under Linux, probably uses Postgre or Firebird and their builtin DB-Security/Usermanagement. 3. Global ServerSingletons using ROT-Entries with FileMonikers... Not supported yet. During a recent rewrite of the ROT implementation I made it easier to do this, but our midl replacement widl isn't quite at the point where this can be implemented yet. Ok, no big problem, if we can get '4.' to work (it's anyway the more recommended way to work with Stateful Objects. 4. RPCServer-internal Singletons ... CoMarshalInterThreadInterfaceInStream and CoGetInterfaceAndReleaseStream ... I'm not sure what you mean here by RPCServer-internal singletons. Please elaborate. Normally RPCs should use stateless objects (Object-Instantiation, Method- Calling, Object-Destroying). That's what we do inside our WorkerThreads. Now there's often the need, to pin an object or some data somewhere between two or more RPCs (for Transactions, Session-Management, Object-Pooling, usage of serverside resources like COM-Ports , etc.). So we allow instantiation of Singleton-Objects inside the RPC- Serverprocess on their own threads (beside the WorkerThreadPool). The two types of singletons behave the same regarding their access from inside the workerthreads (handled unter Windows by the Free- Threaded-Marshaler) - but only the Singletons of Type '3.' can also be accessed from outside (and marshaled) X-Process per GetObject(...). Both of the APIs you mention should be fully functional. I've just tested this using the following VB-Code: Inside the same Thread it works without problems under Wine (altough that makes no sense of course). Cross-Thread it is failing under Wine, whilst the cast of the IUnkn.-Proxy to a second ObjectVariable of Type IDispatch. Maybe, the problem is related to VBs Apartment-Threading and its usage of Thread-Local-Storage (TLS), but it could also be related to incorrect Ref-Counting inside Wine. Here's the Debug-Output of WINEDEBUG=+ole: (First two parts are sucessful, the 3rd-part fails - I've intermitted the Output using MessageBox-related-Breaks http://www.datenhaus.de/Downloads/WineDebug.txt 'here the Types and WinAPI-Declares Private Type GUID Data1 As Long '32Bit-Value Data2 As Integer '16Bit Data3 As Integer '16Bit Data4(0 To 7) As Byte End Type Declare Function CoMarshalInterThreadInterfaceInStream Lib ole32.dll _ (ByRef rIID As Any, ByVal pUnk As IUnknown, ByRef ppStm as Long) Declare Function CoGetInterfaceAndReleaseStream Lib ole32.dll _ (ByVal pStm As Long, ByRef rIID As Any, ByRef pUnk As IUnknown) 'And here the used Functions (last one is failing with a valid pStream-Ptr - 'but only in a Cross-Thread-Scenario) Function GetStreamPtr(ByVal Obj As Object) As Long Dim IID_IUnknown As GUID IID_IUnknown.Data4(0) =
Re: D3D8 caps - wined3d
On Wednesday 22 February 2006 17:21, Stefan Dösinger wrote: Hi, +/* Optimization */ +BOOLmodelview_valid; +BOOLproj_valid; +BOOLview_ident; +BOOLlast_was_rhw; +GLenum tracking_parm; ... Are you sure that this is the latest version of IWineD3DDeviceImpl? I think my patch which added a viewport_changed member here was applied to CVS. I don't have CVS access right now, but I think that the structure you added is out of date. Perhaps my structure is not the latest. I'll check it. (the next patch won't need the structure anymore) Roderick
Re: explorer.exe is a child of new process
Paul Vriens wrote: Hi, with current git/cvs I can see that there is now a new explorer.exe process running when I start process explorer. What is strange though, is that explorer.exe is a child of procexp.exe. Is this supposed to be like that? If Process Explorer uses the systray then yes, it is supposed to be like that. If it bothers you then you can run explorer /systray before starting Process Explorer to emulate the Windows environment better and explorer won't be a child of Process Explorer. -- Rob Shearman
Idea for reducing the number of duplicate bugs
Hi guys, I just wanted to share an idea I just had that could reduce the number of duplicate bugs and ones that have a workaround in the appdb. Many people dont read the documentation, as much as we ask them to, so why dont we, on several pages throughout the website put something that is fairly noticable saying to check the appdb for a workaround/fix before posting a problem to bugzilla, or any of the mailing lists? I think the most helpful places, if we agree to do this, would be the main wine page, the main bugzilla page, the bug submit page, and the main mailing list page.. Something like h2font color=redPlease check the AppDB to see if there is a workaround for a problem you are encountering with a specific program./font/h2 should work for all but the main bug submit page, and there we should put _javascript_:alert('Please check the AppDB to see if there is a workaround for a problem you are encountering with a specific program.'); into the body so that it shows each time they load the page.. Maybe we could make is a question pop up when they hit the submit button instead, and if thye hit yes, then it submits the bug, if not, it either redirects them to the appdb, or back to the bug submit page.
Hopefully most of you will agree and it will get put in.
Tom
Want fun? Try qemu.exe on wine
Hi. SDLVIDEODRIVER=windib wine qemu.exe -L . -hda reactos_0.2.8.img winefile starts inside reactos :-) -- By By ... ... Detlef
Re: Want fun? Run Windows XP on wine
Am Donnerstag, den 23.02.2006, 17:34 +0100 schrieb Detlef Riekenberg: SDLVIDEODRIVER=windib wine qemu.exe -L . -hda reactos_0.2.8.img winefile starts inside reactos :-) Want more fun? Windows XP works also on wine (with qemu.exe) -- By By ... ... Detlef
wine-0.9.8 and Lotus Notes 6.5.1
Hello, just wanted to report my wine experience with Lotus Notes 6.5.1: I run Lotus Notes with wine since a long time. What I notices with wine-0.9.8 (though this was present in a few releases before but not in all releases): - Wine is noticalby faster than the snapshot 200412xx - I need to select win98 to get the file select box working - I need to set WINEDLLOVERRIDES=usp10=n - Cut and paste between X and wine applications works only when selecting the appropriate entry in KDE's klipper. Previously, that worked transparently, when specifying UsePrimary = 1 in the [Clipboard] config stanza - The file select box shows for folders the symbol of files, e.g. Compare [EMAIL PROTECTED]:~/test$ ls -l insgesamt 4 drwxr-xr-x 2 rd rd 4096 2006-02-23 17:08 dir -rw-r--r-- 1 rd rd0 2006-02-23 17:08 file [EMAIL PROTECTED]:~/test$ with the attachment, which shows a screenshot of the file select box. Regards, Rainer -- Rainer Dorsch Alzentalstr. 28 D-71083 Herrenberg 07032-919495 Icq: 32550367 fileselect.png Description: PNG image
Re: wine-0.9.8 and Lotus Notes 6.5.1
--- Rainer Dorsch [EMAIL PROTECTED] wrote: just wanted to report my wine experience with Lotus Notes 6.5.1: I wanted to add that the Wine Application DB is also an excellent place to report Wine experiences with applications: http://appdb.winehq.org/appview.php?versionId=2271 http://appdb.winehq.org/ :) Hiji __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
WineD3D refcounting fun part II :)
Hi, During the d3d8 - wined3d transition I noticed one huge refcounting issue which affects both d3d8 and d3d9. The issue is illustrated by running http://www.codesampler.com/source/dx9_multitexture.zip (the same demo is available for dx8) and then modify wined3d's globalChangeGlRam in wined3d_main.c to let it output how it adjusts the memory. If you run the test on d3d9 or using oliver's full d3d8 patch, you'll notice that not all memory is returned when quitting the program. (In 3dmark2001 this is a big issue as because of this we are out of memory after running a few demos) The problem appears that wined3d surfaces contain a reference to the wined3d device. So when you run a game the d3d8 and wined3d device refcounts are out of sync (the wined3d refcount is a lot higher because of all the refcounts from the surfaces). At the moment you quit a game the d3d8 device refcount nicely becomes zero and the object tries to kill itself. The release function also calls the wined3d device release function but the wined3d device object won't kill itself because its refcount doesn't become zero due to all the surfaces which still contain a reference to it. (the surfaces which useally are front-, backbuffers and more are normally released in the wined3d device release call when the refcount becomes zero) One way to 'fix' the problem is to let d3d8/d3d9 handle the reference counts (remove the refcounts from wined3d; and let d3d8/d3d9 call some cleanup function to remove the garbage in case its refcount becomes zero) Does anyone have a better solution? Roderick
Re: Idea for reducing the number of duplicate bugs
On 2/24/06, Tom Spear [EMAIL PROTECTED] wrote:
Something like h2font color=redPlease check the AppDB to see if there is
a workaround for a problem you are encountering with a specific
program./font/h2 should work for all but the main bug submit page, and
there we should put javascript:alert('Please check the AppDB to see if there
is a workaround for a problem you are encountering with a specific
program.'); into the body so that it shows each time they load the page..
Maybe we could make is a question pop up when they hit the submit button
instead, and if thye hit yes, then it submits the bug, if not, it either
redirects them to the appdb, or back to the bug submit page.
Hopefully most of you will agree and it will get put in.
I really don't think this would reduce bug duplicates. For one thing,
bugs are bugs and should be filed in the database. Even if there's a
workaround in the AppDB that says how to get a program working, it
doesn't mean that the underlying issue shouldn't be fixed.
I also think that having any kind of popup in the way will just annoy
people, and most people will ignore it anyway
n0dalus.
Problems with Sockets and TCL
Hello, I have an app running under Wine called Auctionpay Event Software. Its currently using TCL to implement a SOAP interface. Ive found a bug that can be reproduced with two lines of TCL: package require http http::geturl http://www.google.com timeout 0 query asdf 9 times out of 10 this command will fail to return a page. Sometimes the command works. Ive traced it down the write event not being received by TCL. Looking into Wine, it appears upon connecting to a socket a user message is sent (WM_USER+2). In the handler WSAAsyncSelect is being called. WSAAsyncSelect somehow is triggering the message loop again (possibly in a different thread?!), and the write event seems to be processed before the original WM_USER+2 is completed. This leads to no write event, which leads to no query being posted to the socket, and finally leading to both computers just sitting there until the server drops the socket. Yet 1/10, it seems that the interrupting message processor interrupts the main message loop as WM_USER+2 message handler has exited/is exiting, and the write message is properly processed and the operation works fine. I have been having a terrible time working with winedbg and setting breakpoints (seems to cause crashes). Is there someone interested in working on this bug or possible just shedding some light on just what might be going on to cause the main message loop to be interrupted in a race condition like this? Thanks, Ryan
Idea for reducing the number of duplicate bugs
-- Forwarded message --From: Tom Spear [EMAIL PROTECTED]Date: Feb 23, 2006 3:46 PM
Subject: Re: Idea for reducing the number of duplicate bugsTo: n0dalus [EMAIL PROTECTED]
Ok ok, maybe not an alert. I still think something saying to check the appdb would help, cause then when they read the appdb, they can see that there is already a bug filed for that specific issue, and can post notes to that bug instead of filing a new one.. Sure some users will still file a new one, not paying attention, but it will cut down.. Another thing I think we should do, for the users that do read the docs, is to put a comprehensive guide to searching for a bug ineither the FAQ and/or the wine/developer userguide(s), as the bug search form does look a little intimidating.
Tom
On 2/23/06, n0dalus [EMAIL PROTECTED]
wrote:
On 2/24/06, Tom Spear
[EMAIL PROTECTED] wrote: Something like h2font color=redPlease check the AppDB to see if there is a workaround for a problem you are encountering with a specific program./font/h2 should work for all but the main bug submit page, and
there we should put _javascript_:alert('Please check the AppDB to see if there is a workaround for a problem you are encountering with a specific program.'); into the body so that it shows each time they load the page..
Maybe we could make is a question pop up when they hit the submit button instead, and if thye hit yes, then it submits the bug, if not, it either redirects them to the appdb, or back to the bug submit page.
Hopefully most of you will agree and it will get put in.I really don't think this would reduce bug duplicates. For one thing,bugs are bugs and should be filed in the database. Even if there's a
workaround in the AppDB that says how to get a program working, itdoesn't mean that the underlying issue shouldn't be fixed.I also think that having any kind of popup in the way will just annoypeople, and most people will ignore it anyway
n0dalus.
Re: Guitar Rig 2 in Linux/Wine
On Thu, 2006-02-23 at 09:30 -0500, Kuba Ober wrote: On Monday 20 February 2006 19:34, Michael Ost wrote: We are interested in getting the new Guitar Rig 2 USB foot controller supported in Linux/Wine. It's described here: http://www.native-instruments.com/index.php?id=guitarrig2_us I assume from looking at it, that a USB driver would be required and then perhaps some Wine tweaks to let the plugin open the USB driver. It'd be probably helpful to know more about the device itself. Does it expose snip Kuba, A guy from the linux-audio developers mailing list named Brian Sturk replied and is interested in doing the work. He should be fine with the linux driver side, but pointers in the Wine part of the project might be useful. For now, I am assuming that the work would be open source and integrated into linux and wine in the normal way. I believe the company will be cooperative. Would you care to be CCd on my exchanges with him, or rather just let this one go? I'm fine either way. Thanks for the reply... mo
Debugging
I'm kind of new to the Wine schene. I've dabled in it from time to time; but, seeing the progress it has made I am making a serious effort to get my applications running through Wine rather than VMWare. As such, I'm looking for a little advice on debugging issues when apps don't work (yes, I've read what's on winehq.) I have the application KeePass (keepass.sourceforge.net) which installs just fine. When I go to run it, it just drops me right back to the prompt. With WINEDEBUG, I've tried monitoring the fixme (no results at all), ole, dll, loaddll, system, ntdll, oledlg, olerelay, and rundll32, none of which produced any output that seemed to inducate a problem. I suppose that if Wine sent it a value that it didn't like and they have really good error trapping, the apps could have just shut itself down, but I would think that something must be going wrong somewhere in Wine, but I'm at a loss as to how to find it. I have tried it with the version set to win98 as wekk as win2k and I'm running Wine 0.9.8 (without Winetools), with IE6 installed as per the instructions on appdb.winehq.com. Any advise as to what I can try next or what I should be looking for would be greatly appreciated. -- -- In a world without fences, who needs Gates? pgpJTa26F3l5f.pgp Description: PGP signature
Re: WineD3D refcounting fun part II :)
O right. From the conversation on IRC I got the impression the issue was the application calling the device's Release before calling the surface's Release. Similar to the Surface / Texture issue. On windows that should work, on wine it will probably fail at the moment. Releasing the device after all its children are deleted should work though, and it might simply be a matter of the object (be it a surface or something else) not releasing its references to the device properly upon deletion. I also suspect there might be a couple of circular references in the form of device-stateblock-object-device, but I haven't had time to really look into that yet. I *think* wined3d shouldn't keep references to objects in the device's Set* methods, but I remember that when I removed them in IWineD3DDeviceImpl_SetVertexShader Oliver put them back again in a later patch for some reason.
Re: Debugging
Hi Rich, the key one to use is relay. WINEDEBUG=relay tells you every API function that's called. It can be a bit overwhelming, but it's what you fall back on when nothing else is working. I downloaded and tried it, and scanned backwards in my relay trace a good distance till I saw some failure. Here's what I think it is: 0009:Call kernel32.GetProcAddress(2029,0052b895 BlockInput) ret=0052cc6a 0009:Call ntdll.RtlInitAnsiString(73ccfe20,0052b895 BlockInput) ret=201d2c3e 0009:Ret ntdll.RtlInitAnsiString() retval= ret=201d2c3e 0009:Call ntdll.LdrGetProcedureAddress(2029,73ccfe20,,73ccfe1c) ret=201d2c4d 0009:Ret ntdll.LdrGetProcedureAddress() retval=c07a ret=201d2c4d 0009:Call ntdll.RtlNtStatusToDosError(c07a) ret=201d2c7d 0009:Ret ntdll.RtlNtStatusToDosError() retval=007f ret=201d2c7d 0009:Ret kernel32.GetProcAddress() retval= ret=0052cc6a 0009:Call kernel32.ExitProcess(0052cb10) ret=0052cc7b That is, somebody's trying to get the function BlockInput from kernel32.dll, and it isn't there, so the program exits. I don't know if this is in MFC somewhere, or in the program's source. Luckily the source is available, so you might be able to proceed. Hope that helps, --Juan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Hotkey
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all. I want to fix the hotkey stuff in user.dll. Now i have asked at xorg mail list and thy told me that i should use acpid to do hotkey stuff. Now i think we should to hotkey stuff internal in wine: Have a hash list to save hotkeys and check every time a user presses a button, if there are some pressed other too. If this is also true, look if it is a hotkey and send to the correct window the correct message. What do you think about this? Thanks, Christian - -- Christian Gmeiner - student of computer science http://dxr3plugin.sf.net http://itb04.ath.cx http://javamill.ath.cx -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD/mWCDwe2AbwGBA8RArAOAJ9mfjNBHsdyafLp2exPmY5idH/iFwCfQUjV 4volZ4aoTZNXNxQUtLQCszw= =W3ub -END PGP SIGNATURE-
Re: Debugging
I appreciate the tip about falling back on the relay debug channel, but may I ask how you know the problem is with BlockInput not existing? Is there something from the output that I'm not understanding, or do you just know that because you're familiar with the kernel32.dll code? I'm a long way from ever becoming a Wine developer, but I do want to learn how to either get my programs working, or to be able to accurately identify bugs. On Thursday 23 February 2006 20:18, Juan Lang wrote: Hi Rich, the key one to use is relay. WINEDEBUG=relay tells you every API function that's called. It can be a bit overwhelming, but it's what you fall back on when nothing else is working. I downloaded and tried it, and scanned backwards in my relay trace a good distance till I saw some failure. Here's what I think it is: 0009:Call kernel32.GetProcAddress(2029,0052b895 BlockInput) ret=0052cc6a 0009:Call ntdll.RtlInitAnsiString(73ccfe20,0052b895 BlockInput) ret=201d2c3e 0009:Ret ntdll.RtlInitAnsiString() retval= ret=201d2c3e 0009:Call ntdll.LdrGetProcedureAddress(2029,73ccfe20,,73ccfe1c) ret=201d2c4d 0009:Ret ntdll.LdrGetProcedureAddress() retval=c07a ret=201d2c4d 0009:Call ntdll.RtlNtStatusToDosError(c07a) ret=201d2c7d 0009:Ret ntdll.RtlNtStatusToDosError() retval=007f ret=201d2c7d 0009:Ret kernel32.GetProcAddress() retval= ret=0052cc6a 0009:Call kernel32.ExitProcess(0052cb10) ret=0052cc7b That is, somebody's trying to get the function BlockInput from kernel32.dll, and it isn't there, so the program exits. I don't know if this is in MFC somewhere, or in the program's source. Luckily the source is available, so you might be able to proceed. Hope that helps, --Juan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- -- In a world without fences, who needs Gates? pgp9m04gGTyIZ.pgp Description: PGP signature
Re: Debugging
Rich Gilson wrote: I appreciate the tip about falling back on the relay debug channel, but may I ask how you know the problem is with BlockInput not existing? Is there something from the output that I'm not understanding, or do you just know that because you're familiar with the kernel32.dll code? I'll give it a shot (I'm a chronic newbie so this might be wrong). 0009:Call kernel32.GetProcAddress(2029,0052b895 BlockInput) There's the call asking for an address for BlockInput. 0009:Ret kernel32.GetProcAddress() retval= ret=0052cc6a 0009:Call kernel32.ExitProcess(0052cb10) ret=0052cc7b There the application exits, right after GetProcAddress returns . Look up GetProcAddress in MSDN: http://www.google.com/search?q=GetProcAddressbtnI It says: If the function fails, the return value is NULL. Which seems to be what we're seeing. It also says: To get extended error information, call GetLastError. Luckily, the source code is LGPL and we know that there are bits and pieces missing of it, so an easier way than calling GetLastError is to just grep the sources for kernel32 and see if BlockInput might be missing (probably not a bad guess)... HTH, hope I'm not way off.
Palm Desktop conduits through Wine?
Has there every been any luck/attempts at running Palm Desktop conduits through wine? I'd drop Palm Desktop altogether, but I have Documents-To-Go and Passwords Plus, which both only run through Palm Desktop. From what I can gather from searching around, I'm not going to get Palm Desktop to work on Wine right now, so I'm looking for other alternatives. Thanks. -- -- In a world without fences, who needs Gates? pgpWYybNp12wd.pgp Description: PGP signature
Re: Debugging
I appreciate the tip about falling back on the relay debug channel, but may I ask how you know the problem is with BlockInput not existing? Is there something from the output that I'm not understanding, or do you just know that because you're familiar with the kernel32.dll code? Molle's right--it just looks suspicious, since it's the last thing that's called before ExitProcess. I didn't copy-paste any more of the log, but there were a whole bunch of GetProcAddress calls prior to this that succeeded, which raises the probability that this was the cause. And, as Molle suggested, a quick glance at the kernel32 code shows that BlockInput is missing. As far as how did I spot this in the log--well, that's just experience. You can learn it pretty quickly though, especially when an app dies early. I just scroll through a log from the end toward the beginning, and look for a change in pattern on the screen. Different things are starting to happen there, so I slow down for a closer look. If it looks like normal shutdown code--and there's usually hundreds of lines of this stuff--I ignore it and move on. As far as how to deal with this, try modifying kernel32.spec to add a stub for BlockInput, like: @ stub BlockInput and see if the program gets any further. Chances are it'll crash somewhere else down the line, so you'll have to do the usual wash-rinse-repeat. You should also take a look through KeePass's source code and try to find out what's going on. --Juan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
