Message337838
| Author | eryksun |
|---|---|
| Recipients | brett.cannon, eric.snow, eryksun, jkloth, lukasz.langa, mattip, ncoghlan, paul.moore, steve.dower, tim.golden, zach.ware |
| Date | 2019-03-13.06:50:36 |
| SpamBayes Score | -1.0 |
| Marked as misclassified | Yes |
| Message-id | <1552459836.31.0.188652564605.issue36085@roundup.psfhosted.org> |
| In-reply-to |
| Content | |
|---|---|
> Since I just dug enough to find it, the best way to diagnose problems > with dependent DLLs not being found is probably to run Process Monitor > [1] while doing the import and checking its logs. It should show the > paths that were attempted to be accessed. Don't forget loader snaps, which we can log using a standard debugger such as WinDbg or by attaching a Python script as a debugger (e.g. debug a child process via the DEBUG_PROCESS creation flag). For the latter, we need a debug-event loop (i.e. WaitForDebugEventEx via ctypes) that logs debug-string events. This will show the paths that the loader checks and the load attempts that fail with STATUS_DLL_NOT_FOUND (0xC0000135). We have to first enable loader snaps for the executable by setting a flag value of 2 in the "GlobalFlag" DWORD in the key "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<executable name>". Or use gflags.exe to set this value. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2019-03-13 06:50:36 | eryksun | set | recipients: + eryksun, brett.cannon, paul.moore, ncoghlan, tim.golden, jkloth, lukasz.langa, eric.snow, zach.ware, mattip, steve.dower |
| 2019-03-13 06:50:36 | eryksun | set | messageid: <1552459836.31.0.188652564605.issue36085@roundup.psfhosted.org> |
| 2019-03-13 06:50:36 | eryksun | link | issue36085 messages |
| 2019-03-13 06:50:36 | eryksun | create | |