libwdi-devel Mailing List for libwdi (Page 6)
Windows Driver Installer library for USB devices
Brought to you by:
pbatard
Menu
▾
▴
libwdi-devel — libwdi development
You can subscribe to this list here.
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(2) |
Nov
|
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2012 |
Jan
(6) |
Feb
(40) |
Mar
|
Apr
(11) |
May
|
Jun
(5) |
Jul
(10) |
Aug
(8) |
Sep
(1) |
Oct
(10) |
Nov
(19) |
Dec
(1) |
| 2013 |
Jan
(7) |
Feb
(4) |
Mar
(9) |
Apr
(2) |
May
(1) |
Jun
(7) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
| 2014 |
Jan
(5) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2016 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Pete B. <pb...@gm...> - 2012-02-27 15:54:12
|
On 2012.02.27 15:36, Bob Paddock wrote:
> Up until the 'installer process completed' message comes out,
> installer_x86 is taking ~64% of the CPU in TM.
That's expected, since it is performing the driver installation, which
is a resource heavy task.
> When the 'completed' message comes out, CPU usage drops to the 0->2%
> range, it remains in TM.
Aha. Then there is some function that is blocking at the end of
installer.c, after the line:
send_status(IC_INSTALLER_COMPLETED);
This send_status is responsible for the "installer process completed"
message we get in wdi-simple, but there isn't much of anything that
should be blocking after that.
This is the current ending section:
out:
// Report any error status code and wait for target app to read it
send_status(IC_INSTALLER_COMPLETED);
pstat(ret);
// Restore the system restore point creation original settings
disable_system_restore(false);
// TODO: have libwi send an ACK?
Sleep(1000);
SetEvent(syslog_terminate_event);
if (argv != argv_ansi) {
for (i=0; i<argc; i++) {
safe_free(argv[i]);
}
safe_free(argv);
}
CloseHandle(syslog_ready_event);
CloseHandle(syslog_terminate_event);
CloseHandle((HANDLE)syslog_reader_thid);
CloseHandle(pipe_handle);
return ret;
}
pstat() (which sets the process return code), Sleep() and SetEvent() are
not expected to be blocking (well, Sleep technically is, but only for 1
second). Likewise the freeing up or widechar argv resources wouldn't be
blocking.
Thus, it's either the disable_system_restore or, more likely, one of the
non event related CloseHandle that does us in.
If you are recompiling libwdi altogether, you should be able to
interstep some:
plog("some message");
lines up to the closure of the pipe_handle.
If not, let me know, and I'll try to produce a wdi-simple.exe that
embeds an installer with extra debug, so that we can identify the culprit.
Regards,
/Pete
|
|
From: Bob P. <gra...@gm...> - 2012-02-27 15:36:58
|
> Thanks for the report, and sorry if I wasn't clear there, but my question > was actually about whether the installer_x86.exe or installer_x64.exe > process, which is a separate executable launched by wdi-simple.exe to > perform the actual installation, was listed in the task manager. Up until the 'installer process completed' message comes out, installer_x86 is taking ~64% of the CPU in TM. When the 'completed' message comes out, CPU usage drops to the 0->2% range, it remains in TM. After the ~30 seconds installer_x86 and wdi-simple both leave TM. |
|
From: Pete B. <pb...@gm...> - 2012-02-27 15:26:47
|
On 2012.02.27 15:16, Bob Paddock wrote: >> OK. But do you see it in task manager until the timeout? > > Yes, I also see it on 'Seccess'. > > Time of events are: > > libwdi:debug [process_message] installer process completed > > ~30 seconds pass with wdi-simple.exe visible in Task Manager. > > Then either the message 'Success' or 'Time Out' comes up. > I don't really see any difference in anything to installing my device, > regardless of which message came out. > > wdi-simple.exe is then gone from Task Manager. Thanks for the report, and sorry if I wasn't clear there, but my question was actually about whether the installer_x86.exe or installer_x64.exe process, which is a separate executable launched by wdi-simple.exe to perform the actual installation, was listed in the task manager. Its presence when the timeout occurs will tell us if the issue is with the installer not exiting properly, or with libwdi missing the exit notification. Regards, /Pete |
|
From: Bob P. <gra...@gm...> - 2012-02-27 15:16:21
|
> OK. But do you see it in task manager until the timeout? Yes, I also see it on 'Seccess'. Time of events are: libwdi:debug [process_message] installer process completed ~30 seconds pass with wdi-simple.exe visible in Task Manager. Then either the message 'Success' or 'Time Out' comes up. I don't really see any difference in anything to installing my device, regardless of which message came out. wdi-simple.exe is then gone from Task Manager. |
|
From: Bob P. <bob...@gm...> - 2012-02-24 00:02:11
|
> OK. But do you see it in task manager until the timeout? I think so. I will check for sure on Monday. |
|
From: Bob P. <bob...@gm...> - 2012-02-24 00:01:03
|
> Which libwdi application are you using? wdi-simple does not take an ini > file and I thought this is what you were using. Are you using something > else? Should have said .inf. I don't thinkg libwdi is involved in this problem, just hoped someone here would have an idea. |
|
From: Pete B. <pb...@gm...> - 2012-02-23 18:58:48
|
On 2012.02.23 18:00, Bob Paddock wrote:
>> Are you saying that, if your timeout is set to 30 seconds, you get the
>> "installer process completed" and then 30 seconds later the timeout message?
>
> Yes.
OK, that would seem to indicate that the installer process is stuck on
closure.
Another possibility is that we got the broken pipe event but missed the
process close event, in which case the timeout is benign (but I will
need to modify the closure detection code).
> libwdi:debug [syslog] ndv: System restore disabled by policy
> . Error = 0x000004EC
>
> News to me. Will have to find what policy has it disabled.
This message is expected. Libwdi does disable system restore, to speed
up the installation process, and this log entry indicated that Windows
did indeed properly detect that it was disabled. If there was an issue,
we would get a message that isn't prefixed with [syslog].
> Is there a way to output arbitrary text to the log?
> I use __FILE__ __func__ __LINE__ in my embedded code like so:
>
> #define DEBUG_FILE_LINE_OUT( DEBUG_LEVEL_U16, VALUE_U32 ) do{
> debug_file_line_out( DEBUG_LEVEL_U16, __FILE__, __func__, (uint16_t)
> __LINE__, (uint32_t) VALUE_U32 ); }while(0)
>
> so logs look like:
> [FILE]/[FUNCTION] [LINE] :
> FileName.c/MyCoolFunction 1234.
>
> The naming of __func__ varies with compilers sometimes it is __FUNC__,
> __FUNCTION__ or __PRETTY_FUNCTION__
> http://gcc.gnu.org/onlinedocs/gcc/Function-Names.html gives some info.
> __func__ is the C99 standard.
> The great thing about standards is that everyone can have one. :-(
If you're in the installer.c, plog() will send a message to the logging
facility. If you're in libwdi itself, wdi_dbg(), wdi_warn() or wdi_err()
will produce log messages. I didn't add the __FILE__ & __func__ calls to
the logging facility because I didn't see the need for those so far (the
codebase is fairly small).
>> Can you also confirm that you still see the installer process in task
>> manager after the timeout message?
>
> It is not in the task manager after getting the timeout error.
OK. But do you see it in task manager until the timeout?
I think knowing this will answer the question of whether the installer
process is stuck, or we missed one of the closure event.
Regards,
/Pete
PS: the logs don't show anything suspicious besides the timeout.
|
|
From: Pete B. <pb...@gm...> - 2012-02-23 18:47:17
|
On 2012.02.23 18:38, Bob Paddock wrote: > The 9A00 is in the .ini file. I'm not entering any command line IDs. > Don't really think it would be the case of 'A' vs 'a' but nothing else > changed but the PIDs. Which libwdi application are you using? wdi-simple does not take an ini file and I thought this is what you were using. Are you using something else? Regards, /Pete |
|
From: Bob P. <gra...@gm...> - 2012-02-23 18:38:42
|
> If you are using wdi_simple, be mindful that you have to prefix 0x for > any hex value. This should be documented with "wdi-simple --help" > -p, --pid <id> set the product ID (PID, use 0x prefix for hex) The 9A00 is in the .ini file. I'm not entering any command line IDs. Don't really think it would be the case of 'A' vs 'a' but nothing else changed but the PIDs. If you really want to mess up peoples minds go with leading zeros make it Octal (Base-8), the standard C convention. :-) |
|
From: Pete B. <pb...@gm...> - 2012-02-23 18:26:06
|
On 2012.02.23 18:20, Bob Paddock wrote: > Are PID's case sensitive? Nothing I can find says that the PIDs in a > .ini file are case sensitive. > > In my .ini and device, I changed PID from 0015 which worked fine, to > 9A00 that won't install at all. I don't get it. If you are using wdi_simple, be mindful that you have to prefix 0x for any hex value. This should be documented with "wdi-simple --help" -p, --pid <id> set the product ID (PID, use 0x prefix for hex) Regards, /Pete |
|
From: Bob P. <gra...@gm...> - 2012-02-23 18:20:09
|
Are PID's case sensitive? Nothing I can find says that the PIDs in a
.ini file are case sensitive.
In my .ini and device, I changed PID from 0015 which worked fine, to
9A00 that won't install at all. I don't get it.
>>> [Device Install (Hardware initiated) - USB\VID_xxxx&PID_9A00\YYV9H745]
>>> Section start 2012/02/22 12:15:18.019
ump: Creating Install Process: DrvInst.exe 12:15:18.026
ndv: Retrieving device info...
ndv: Setting device parameters...
ndv: Searching just Driver Store...
dvi: {Build Driver List} 12:15:18.041
dvi: Searching for hardware ID(s):
dvi: usb\vid_xxxx&pid_9a00&rev_0600
dvi: usb\vid_xxxx&pid_9a00
dvi: Searching for compatible ID(s):
dvi: usb\class_ff&subclass_ff&prot_ff
dvi: usb\class_ff&subclass_ff
dvi: usb\class_ff
cpy: Policy is set to make all digital signatures equal.
dvi: Enumerating INFs from path list 'C:\Windows\INF'
inf: Searched 0 potential matches in published INF directory
inf: Searched 49 INFs in directory: 'C:\Windows\INF'
dvi: {Build Driver List - exit(0x00000000)} 12:15:18.114
ndv: Selecting best match from just Driver Store...
dvi: {DIF_SELECTBESTCOMPATDRV} 12:15:18.117
dvi: No class installer for 'My Device'
dvi: No CoInstallers found
dvi: Default installer: Enter 12:15:18.117
dvi: {Select Best Driver}
! dvi: Selecting driver failed(0xe0000228)
dvi: {Select Best Driver - exit(0xe0000228)}
! dvi: Default installer: failed!
! dvi: Error 0xe0000228: There are no compatible drivers for
this device.
|
|
From: Bob P. <gra...@gm...> - 2012-02-23 18:00:10
|
On Thu, Feb 23, 2012 at 6:09 AM, Pete Batard <pb...@gm...> wrote:
> On 2012.02.22 16:37, Bob Paddock wrote:
>>
>> Yes, I see those messages. Tried time out of 30000 as well, same results.
>>
>> What I find odd is I see "installer process completed" then *after*
>> the timeout period is when I get the "operation timed out".
>
>
> Can you send a complete debug log then?
Below. Win7 then XP.
> Are you saying that, if your timeout is set to 30 seconds, you get the
> "installer process completed" and then 30 seconds later the timeout message?
Yes.
> If that's the case, it would indicate that the installer process blocks in:
> - restoring the system restore point creation to its original settings (but
> then I would expect your log to show an error at the beginning when we try
> to disable the restore points)
libwdi:debug [syslog] ndv: System restore disabled by policy
. Error = 0x000004EC
News to me. Will have to find what policy has it disabled.
I also see in the log that my catalogs are not signed correctly again. :-(
Will make that a separate message, to not get distracted from this
timeout issue.
> A crude way to find which of these operations is the cause of the timeout
> would be to add a "send_status(IC_INSTALLER_COMPLETED);" line after each of
> the potentially blocking calls of the "out:" section at the bottom of
> installer.c. Then if you count the "drive installation completed" messages,
> it should be easy to find out which operation is the blocking one.
If the log doesn't help, then I'll go that route.
Is there a way to output arbitrary text to the log?
I use __FILE__ __func__ __LINE__ in my embedded code like so:
#define DEBUG_FILE_LINE_OUT( DEBUG_LEVEL_U16, VALUE_U32 ) do{
debug_file_line_out( DEBUG_LEVEL_U16, __FILE__, __func__, (uint16_t)
__LINE__, (uint32_t) VALUE_U32 ); }while(0)
so logs look like:
[FILE]/[FUNCTION] [LINE] :
FileName.c/MyCoolFunction 1234.
The naming of __func__ varies with compilers sometimes it is __FUNC__,
__FUNCTION__ or __PRETTY_FUNCTION__
http://gcc.gnu.org/onlinedocs/gcc/Function-Names.html gives some info.
__func__ is the C99 standard.
The great thing about standards is that everyone can have one. :-(
> Can you also confirm that you still see the installer process in task
> manager after the timeout message?
It is already in the Windows7 driver store so doing it again does not
generate the message.
Log below are from Windows7. Will try XP. Okay, under XP I get the
timeout error every time.
It is not in the task manager after getting the timeout error.
>> I had not noticed that discrepancy with the ten second timeout.
>
>
> Does that mean that it doesn't occur with the ten second timeout or that you
> just didn't notice it?
At the ten second timeout they happen about the same time, so I did
not notice it.
Win7:
libwdi:debug [syslog] flq: MoveFile: 'C:\Users\BOBP~1\A
ppData\Local\Temp\{3c17a58f-3909-3b8d-bf26-6166845dca23}\amd64\SET40D4.tmp'
libwdi:debug [syslog] flq: to: 'C:\Users\BOBP~1\A
ppData\Local\Temp\{3c17a58f-3909-3b8d-bf26-6166845dca23}\amd64\ftcserco.dll'
libwdi:debug [syslog] flq: {_commit_copyfile exit OK}
libwdi:debug [syslog] flq: source media:
libwdi:debug [syslog] flq: SourcePath - [D:\Projects\
USB\libwdi-1.2.1\examples\usb_driver]
libwdi:debug [syslog] flq: SourceFile - [usb_port.cat
]
libwdi:debug [syslog] flq: Flags - 0x00000000
libwdi:debug [syslog] flq: {_commit_copyfile}
libwdi:debug [syslog] flq: CopyFile: 'D:\Projects\USB\l
ibwdi-1.2.1\examples\usb_driver\usb_port.cat'
libwdi:debug [syslog] flq: to: 'C:\Users\BOBP~1\A
ppData\Local\Temp\{3c17a58f-3909-3b8d-bf26-6166845dca23}\SET40E5.tmp'
libwdi:debug [syslog] flq: MoveFile: 'C:\Users\BOBP~1\A
ppData\Local\Temp\{3c17a58f-3909-3b8d-bf26-6166845dca23}\SET40E5.tmp'
libwdi:debug [syslog] flq: to: 'C:\Users\BOBP~1\A
ppData\Local\Temp\{3c17a58f-3909-3b8d-bf26-6166845dca23}\usb_port.cat'
libwdi:debug [syslog] flq: {_commit_copyfile exit OK}
libwdi:debug [syslog] flq: {_commit_copyfile}
libwdi:debug [syslog] flq: CopyFile: 'D:\Projects\USB\l
ibwdi-1.2.1\examples\usb_driver\usb_port.inf'
libwdi:debug [syslog] flq: to: 'C:\Users\BOBP~1\A
ppData\Local\Temp\{3c17a58f-3909-3b8d-bf26-6166845dca23}\SET40F5.tmp'
libwdi:debug [syslog] flq: MoveFile: 'C:\Users\BOBP~1\A
ppData\Local\Temp\{3c17a58f-3909-3b8d-bf26-6166845dca23}\SET40F5.tmp'
libwdi:debug [syslog] flq: to: 'C:\Users\BOBP~1\A
ppData\Local\Temp\{3c17a58f-3909-3b8d-bf26-6166845dca23}\usb_port.inf'
libwdi:debug [syslog] flq: {_commit_copyfile exit OK}
libwdi:debug [syslog] flq: {_commit_copy_subqueue exit OK}
libwdi:debug [syslog] flq: {_commit_file_queue exit OK}
libwdi:debug [syslog] pol: {Driver package policy check} 10:52:24.193
libwdi:debug [syslog] pol: {Driver package policy check - exit(0x00000
000)} 10:52:24.195
libwdi:debug [syslog] sto: {Stage Driver Package: C:\Users\BOBP~1\AppD
ata\Local\Temp\{3c17a58f-3909-3b8d-bf26-6166845dca23}\usb_port.inf} 10:52:24.195
libwdi:debug [syslog] inf: Opened INF: 'C:\Users\BOBP~1\AppData\L
ocal\Temp\{3c17a58f-3909-3b8d-bf26-6166845dca23}\usb_port.inf' ([strings])
libwdi:debug [syslog] inf: Opened INF: 'C:\Users\BOBP~1\AppData\L
ocal\Temp\{3c17a58f-3909-3b8d-bf26-6166845dca23}\usb_port.inf' ([strings])
libwdi:debug [syslog] sto: Copying driver package files:
libwdi:debug [syslog] sto: Source Path = C:\Users\BOBP~
1\AppData\Local\Temp\{3c17a58f-3909-3b8d-bf26-6166845dca23}
libwdi:debug [syslog] sto: Destination Path = C:\Windows\Sys
tem32\DriverStore\Temp\{65983b40-0641-6820-632b-5f4b7771dc34}
libwdi:debug [syslog] flq: {FILE_QUEUE_COPY}
libwdi:debug [syslog] flq: CopyStyle - 0x00000010
libwdi:debug [syslog] flq: SourceRootPath - 'C:\Users\BOBP~1
\AppData\Local\Temp\{3c17a58f-3909-3b8d-bf26-6166845dca23}\amd64'
libwdi:debug [syslog] flq: SourceFilename - 'ftser2k.sys'
libwdi:debug [syslog] flq: TargetDirectory- 'C:\Windows\Syst
em32\DriverStore\Temp\{65983b40-0641-6820-632b-5f4b7771dc34}\amd64'
libwdi:debug [syslog] flq: {FILE_QUEUE_COPY exit(0x00000000)}
libwdi:debug [syslog] flq: {FILE_QUEUE_COPY}
libwdi:debug [syslog] flq: CopyStyle - 0x00000010
libwdi:debug [syslog] flq: SourceRootPath - 'C:\Users\BOBP~1
\AppData\Local\Temp\{3c17a58f-3909-3b8d-bf26-6166845dca23}'
libwdi:debug [syslog] flq: SourceFilename - 'usb_port.cat'
libwdi:debug [syslog] flq: TargetDirectory- 'C:\Windows\Syst
em32\DriverStore\Temp\{65983b40-0641-6820-632b-5f4b7771dc34}'
libwdi:debug [syslog] flq: {FILE_QUEUE_COPY exit(0x00000000)}
libwdi:debug [syslog] flq: {FILE_QUEUE_COPY}
libwdi:debug [syslog] flq: CopyStyle - 0x00000010
libwdi:debug [syslog] flq: SourceRootPath - 'C:\Users\BOBP~1
\AppData\Local\Temp\{3c17a58f-3909-3b8d-bf26-6166845dca23}'
libwdi:debug [syslog] flq: SourceFilename - 'usb_port.inf'
libwdi:debug [syslog] flq: TargetDirectory- 'C:\Windows\Syst
em32\DriverStore\Temp\{65983b40-0641-6820-632b-5f4b7771dc34}'
libwdi:debug [syslog] flq: {FILE_QUEUE_COPY exit(0x00000000)}
libwdi:debug [syslog] flq: {FILE_QUEUE_COPY}
libwdi:debug [syslog] flq: CopyStyle - 0x00000010
libwdi:debug [syslog] flq: SourceRootPath - 'C:\Users\BOBP~1
\AppData\Local\Temp\{3c17a58f-3909-3b8d-bf26-6166845dca23}\amd64'
libwdi:debug [syslog] flq: SourceFilename - 'ftserui2.dll'
libwdi:debug [syslog] flq: TargetDirectory- 'C:\Windows\Syst
em32\DriverStore\Temp\{65983b40-0641-6820-632b-5f4b7771dc34}\amd64'
libwdi:debug [syslog] flq: {FILE_QUEUE_COPY exit(0x00000000)}
libwdi:debug [syslog] flq: {FILE_QUEUE_COPY}
libwdi:debug [syslog] flq: CopyStyle - 0x00000010
libwdi:debug [syslog] flq: SourceRootPath - 'C:\Users\BOBP~1
\AppData\Local\Temp\{3c17a58f-3909-3b8d-bf26-6166845dca23}\amd64'
libwdi:debug [syslog] flq: SourceFilename - 'ftcserco.dll'
libwdi:debug [syslog] flq: TargetDirectory- 'C:\Windows\Syst
em32\DriverStore\Temp\{65983b40-0641-6820-632b-5f4b7771dc34}\amd64'
libwdi:debug [syslog] flq: {FILE_QUEUE_COPY exit(0x00000000)}
libwdi:debug [syslog] flq: {_commit_file_queue}
libwdi:debug [syslog] flq: CommitQ DelNodes=0 RenNodes=0 Cop
yNodes=5
libwdi:debug [syslog] flq: {_commit_copy_subqueue}
libwdi:debug [syslog] flq: subqueue count=5
libwdi:debug [syslog] flq: source media:
libwdi:debug [syslog] flq: SourcePath - [C:\User
s\BOBP~1\AppData\Local\Temp\{3c17a58f-3909-3b8d-bf26-6166845dca23}\amd64]
libwdi:debug [syslog] flq: SourceFile - [ftser2k
.sys]
libwdi:debug [syslog] flq: Flags - 0x000000
00
libwdi:debug [syslog] flq: {_commit_copyfile}
libwdi:debug [syslog] flq: CopyFile: 'C:\Users\BOB
P~1\AppData\Local\Temp\{3c17a58f-3909-3b8d-bf26-6166845dca23}\amd64\ftser2k.sys'
libwdi:debug [syslog] flq: to: 'C:\Windows\S
ystem32\DriverStore\Temp\{65983b40-0641-6820-632b-5f4b7771dc34}\amd64\SETC0E9.tm
p'
libwdi:debug [syslog] flq: MoveFile: 'C:\Windows\S
ystem32\DriverStore\Temp\{65983b40-0641-6820-632b-5f4b7771dc34}\amd64\SETC0E9.tm
p'
libwdi:debug [syslog] flq: to: 'C:\Windows\S
ystem32\DriverStore\Temp\{65983b40-0641-6820-632b-5f4b7771dc34}\amd64\ftser2k.sy
s'
libwdi:debug [syslog] flq: {_commit_copyfile exit OK}
libwdi:debug [syslog] flq: {_commit_copyfile}
libwdi:debug [syslog] flq: CopyFile: 'C:\Users\BOB
P~1\AppData\Local\Temp\{3c17a58f-3909-3b8d-bf26-6166845dca23}\amd64\ftserui2.dll
'
libwdi:debug [syslog] flq: to: 'C:\Windows\S
ystem32\DriverStore\Temp\{65983b40-0641-6820-632b-5f4b7771dc34}\amd64\SETC0FA.tm
p'
libwdi:debug [syslog] flq: MoveFile: 'C:\Windows\S
ystem32\DriverStore\Temp\{65983b40-0641-6820-632b-5f4b7771dc34}\amd64\SETC0FA.tm
p'
libwdi:debug [syslog] flq: to: 'C:\Windows\S
ystem32\DriverStore\Temp\{65983b40-0641-6820-632b-5f4b7771dc34}\amd64\ftserui2.d
ll'
libwdi:debug [syslog] flq: {_commit_copyfile exit OK}
libwdi:debug [syslog] flq: {_commit_copyfile}
libwdi:debug [syslog] flq: CopyFile: 'C:\Users\BOB
P~1\AppData\Local\Temp\{3c17a58f-3909-3b8d-bf26-6166845dca23}\amd64\ftcserco.dll
'
libwdi:debug [syslog] flq: to: 'C:\Windows\S
ystem32\DriverStore\Temp\{65983b40-0641-6820-632b-5f4b7771dc34}\amd64\SETC11A.tm
p'
libwdi:debug [syslog] flq: MoveFile: 'C:\Windows\S
ystem32\DriverStore\Temp\{65983b40-0641-6820-632b-5f4b7771dc34}\amd64\SETC11A.tm
p'
libwdi:debug [syslog] flq: to: 'C:\Windows\S
ystem32\DriverStore\Temp\{65983b40-0641-6820-632b-5f4b7771dc34}\amd64\ftcserco.d
ll'
libwdi:debug [syslog] flq: {_commit_copyfile exit OK}
libwdi:debug [syslog] flq: source media:
libwdi:debug [syslog] flq: SourcePath - [C:\User
s\BOBP~1\AppData\Local\Temp\{3c17a58f-3909-3b8d-bf26-6166845dca23}]
libwdi:debug [syslog] flq: SourceFile - [usb_por
t.cat]
libwdi:debug [syslog] flq: Flags - 0x000000
00
libwdi:debug [syslog] flq: {_commit_copyfile}
libwdi:debug [syslog] flq: CopyFile: 'C:\Users\BOB
P~1\AppData\Local\Temp\{3c17a58f-3909-3b8d-bf26-6166845dca23}\usb_port.cat'
libwdi:debug [syslog] flq: to: 'C:\Windows\S
ystem32\DriverStore\Temp\{65983b40-0641-6820-632b-5f4b7771dc34}\SETC12B.tmp'
libwdi:debug [syslog] flq: MoveFile: 'C:\Windows\S
ystem32\DriverStore\Temp\{65983b40-0641-6820-632b-5f4b7771dc34}\SETC12B.tmp'
libwdi:debug [syslog] flq: to: 'C:\Windows\S
ystem32\DriverStore\Temp\{65983b40-0641-6820-632b-5f4b7771dc34}\usb_port.cat'
libwdi:debug [syslog] flq: {_commit_copyfile exit OK}
libwdi:debug [syslog] flq: {_commit_copyfile}
libwdi:debug [syslog] flq: CopyFile: 'C:\Users\BOB
P~1\AppData\Local\Temp\{3c17a58f-3909-3b8d-bf26-6166845dca23}\usb_port.inf'
libwdi:debug [syslog] flq: to: 'C:\Windows\S
ystem32\DriverStore\Temp\{65983b40-0641-6820-632b-5f4b7771dc34}\SETC12C.tmp'
libwdi:debug [syslog] flq: MoveFile: 'C:\Windows\S
ystem32\DriverStore\Temp\{65983b40-0641-6820-632b-5f4b7771dc34}\SETC12C.tmp'
libwdi:debug [syslog] flq: to: 'C:\Windows\S
ystem32\DriverStore\Temp\{65983b40-0641-6820-632b-5f4b7771dc34}\usb_port.inf'
libwdi:debug [syslog] flq: {_commit_copyfile exit OK}
libwdi:debug [syslog] flq: {_commit_copy_subqueue exit OK}
libwdi:debug [syslog] flq: {_commit_file_queue exit OK}
libwdi:debug [syslog] sto: {DRIVERSTORE_IMPORT_NOTIFY_VALIDATE} 1
0:53:07.873
libwdi:debug [syslog] inf: Opened INF: 'C:\Windows\System32\
DriverStore\Temp\{65983b40-0641-6820-632b-5f4b7771dc34}\usb_port.inf' ([strings]
)
libwdi:debug [syslog] sig: {_VERIFY_FILE_SIGNATURE} 10:53:18
.755
libwdi:debug [syslog] sig: Key = usb_port.inf
libwdi:debug [syslog] sig: FilePath = C:\Windows\System
32\DriverStore\Temp\{65983b40-0641-6820-632b-5f4b7771dc34}\usb_port.inf
libwdi:debug [syslog] sig: Catalog = C:\Windows\System
32\DriverStore\Temp\{65983b40-0641-6820-632b-5f4b7771dc34}\usb_port.cat
libwdi:debug [syslog] flq: {SPFILENOTIFY_CABINETINFO}
libwdi:debug [syslog] flq: {SPFILENOTIFY_CABINETINFO -
exit(0x00000000)}
libwdi:debug [syslog] flq: {SPFILENOTIFY_FILEEXTRACTED}
libwdi:debug [syslog] flq: {SPFILENOTIFY_FILEEXTRACTED
- exit(0x00000000)}
libwdi:debug [syslog] ! sig: Verifying file against speci
fic (valid) catalog failed! (0x800b0109)
libwdi:debug [syslog] ! sig: Error 0x800b0109: A certific
ate chain processed, but terminated in a root certificate which is not trusted b
y the trust provider.
libwdi:debug [syslog] sig: {_VERIFY_FILE_SIGNATURE exit(0x80
0b0109)} 10:53:18.858
libwdi:debug [syslog] sig: {_VERIFY_FILE_SIGNATURE} 10:53:18
.858
libwdi:debug [syslog] sig: Key = usb_port.inf
libwdi:debug [syslog] sig: FilePath = C:\Windows\System
32\DriverStore\Temp\{65983b40-0641-6820-632b-5f4b7771dc34}\usb_port.inf
libwdi:debug [syslog] sig: Catalog = C:\Windows\System
32\DriverStore\Temp\{65983b40-0641-6820-632b-5f4b7771dc34}\usb_port.cat
libwdi:debug [syslog] sig: Success: File is signed in A
uthenticode(tm) catalog.
libwdi:debug [syslog] sig: Error 0xe0000242: The publis
her of an Authenticode(tm) signed catalog has not yet been established as truste
d.
libwdi:debug [syslog] sig: {_VERIFY_FILE_SIGNATURE exit(0xe0
000242)} 10:53:18.980
libwdi:debug [syslog] sto: Validating driver package files a
gainst catalog 'usb_port.cat'.
libwdi:debug [syslog] ! sto: Driver package signer is unknown
but user trusts the signer.
libwdi:debug [syslog] sto: {DRIVERSTORE_IMPORT_NOTIFY_VALIDATE ex
it(0x00000000)} 10:53:43.353
libwdi:debug [syslog] sto: Verified driver package signature:
libwdi:debug [syslog] sto: Digital Signer Score = 0xFF000000
libwdi:debug [syslog] sto: Digital Signer Name = <unknown>
libwdi:debug [syslog] sto: {DRIVERSTORE_IMPORT_NOTIFY_BEGIN} 10:5
3:43.355
libwdi:debug [syslog] ndv: System restore disabled by policy
. Error = 0x000004EC
libwdi:debug [syslog] sto: {DRIVERSTORE_IMPORT_NOTIFY_BEGIN: exit
(0x00000000)} 10:53:43.358
libwdi:debug [syslog] sto: Importing driver package files:
libwdi:debug [syslog] sto: Source Path = C:\Windows\Sys
tem32\DriverStore\Temp\{65983b40-0641-6820-632b-5f4b7771dc34}
libwdi:debug [syslog] sto: Destination Path = C:\Windows\Sys
tem32\DriverStore\FileRepository\usb_port.inf_amd64_neutral_397def8cdb62f5aa
libwdi:debug [syslog] sto: {Copy Directory: C:\Windows\System32\D
riverStore\Temp\{65983b40-0641-6820-632b-5f4b7771dc34}} 10:53:43.370
libwdi:debug [syslog] sto: Target Path = C:\Windows\System32
\DriverStore\FileRepository\usb_port.inf_amd64_neutral_397def8cdb62f5aa
libwdi:debug [syslog] sto: {Copy Directory: C:\Windows\Syste
m32\DriverStore\Temp\{65983b40-0641-6820-632b-5f4b7771dc34}\amd64} 10:53:43.373
libwdi:debug [syslog] sto: Target Path = C:\Windows\Sys
tem32\DriverStore\FileRepository\usb_port.inf_amd64_neutral_397def8cdb62f5aa\amd
64
libwdi:debug [syslog] sto: {Copy Directory: exit(0x00000000)
} 10:53:43.375
libwdi:debug [syslog] sto: {Copy Directory: exit(0x00000000)} 10:
53:43.375
libwdi:debug [syslog] sto: {Index Driver Package: C:\Windows\Syst
em32\DriverStore\FileRepository\usb_port.inf_amd64_neutral_397def8cdb62f5aa\usb_
port.inf} 10:53:43.375
libwdi:debug [syslog] idb: Registered driver store entry 'us
b_port.inf_amd64_neutral_397def8cdb62f5aa'.
libwdi:debug [syslog] idb: Published 'usb_port.inf_amd64_neu
tral_397def8cdb62f5aa\usb_port.inf' to 'C:\Windows\INF\oem35.inf'
libwdi:debug [syslog] idb: Published driver store entry 'usb
_port.inf_amd64_neutral_397def8cdb62f5aa'.
libwdi:debug [syslog] sto: Published driver package INF 'oem
35.inf' was changed.
libwdi:debug [syslog] sto: Active published driver package i
s 'usb_port.inf_amd64_neutral_397def8cdb62f5aa'.
libwdi:debug [syslog] sto: {Index Driver Package: exit(0x00000000
)} 10:54:28.035
libwdi:debug [syslog] sto: {DRIVERSTORE_IMPORT_NOTIFY_END} 10:54:
28.035
libwdi:debug [syslog] ndv: No system restore point was set e
arlier.
libwdi:debug [syslog] sto: {DRIVERSTORE_IMPORT_NOTIFY_END: exit(0
x00000000)} 10:54:28.038
libwdi:debug [syslog] sto: {Stage Driver Package: exit(0x00000000)} 10
:54:28.048
libwdi:debug [syslog] ndv: Doing device matching lookup!
libwdi:debug [syslog] inf: Opened INF: 'C:\Windows\System32\DriverStor
e\FileRepository\usb_port.inf_amd64_neutral_397def8cdb62f5aa\usb_port.inf' ([str
ings])
libwdi:debug [syslog] inf: Saved PNF: 'C:\Windows\System32\DriverStore
\FileRepository\usb_port.inf_amd64_neutral_397def8cdb62f5aa\usb_port.PNF' (Langu
age = 0409)
libwdi:debug [syslog] sto: Driver package was staged to Driver Store.
Time = 134956 ms
libwdi:debug [syslog] sto: Imported driver package into Driver Store:
libwdi:debug [syslog] sto: Filename = C:\Windows\System32\DriverS
tore\FileRepository\usb_port.inf_amd64_neutral_397def8cdb62f5aa\usb_port.inf
libwdi:debug [syslog] sto: Time = 178668 ms
libwdi:debug [syslog] sto: {Import Driver Package: exit(0x00000000)} 10:54:
39.148
libwdi:debug [syslog] inf: Opened INF: 'D:\Projects\USB\libwdi-1.2.1\exampl
es\usb_driver\usb_port.inf' ([strings])
libwdi:debug [syslog] inf: Driver Store location: C:\Windows\System32\Drive
rStore\FileRepository\usb_port.inf_amd64_neutral_397def8cdb62f5aa\usb_port.inf
libwdi:debug [syslog] inf: Published Inf Path: C:\Windows\INF\oem35.inf
libwdi:debug [process_message] switching timeout back to finite
libwdi:debug [installer process] copied inf to C:\Windows\INF\oem35.inf
libwdi:debug [installer process] re-enumerating driver node <root>...
libwdi:debug [syslog] inf: Opened INF: 'D:\Projects\USB\libwdi-1.2.1\exampl
es\usb_driver\usb_port.inf' ([strings])
libwdi:debug [syslog] inf: Installing catalog usb_port.cat as: oem35.CAT
libwdi:debug [syslog] <<< Section end 2012/02/23 10:55:11.525
libwdi:debug [syslog] <<< [Exit status: SUCCESS]
libwdi:error [install_driver_internal] installer failed to respond - aborting
Operation timed out
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Temp>wdi-simple -l 0 --type 3 --inf usb_port.inf
Extracting driver files...
libwdi:info [wdi_prepare_driver] custom driver - extracting binaries only (no in
f/cat creation)
libwdi:info [extract_binaries] successfully extracted driver files to usb_driver
Success
Installing driver(s)...
libwdi:debug [wdi_install_driver] using standard mode
libwdi:info [detect_version] Windows XP
libwdi:debug [installer process] got parameter usb_port.inf
libwdi:debug [process_message] got request for device_id
libwdi:debug [process_message] no device_id - sending empty string
libwdi:debug [installer process] got device_id: ''
libwdi:debug [process_message] got request for hardware_id
libwdi:debug [process_message] no hardware_id - sending empty string
libwdi:debug [installer process] got hardware_id: ''
libwdi:debug [installer process] got user_sid: 'S-1-5-21-2874270858-3612603723-1
097136059-1003'
libwdi:debug [installer process] using syslog 'C:\WINDOWS\setupapi.log'
libwdi:debug [installer process] sylog reader thread started
libwdi:debug [process_message] switching timeout to infinite
libwdi:debug [installer process] Copying inf file (for the next time device is p
lugged) - please wait...
libwdi:debug [process_message] switching timeout to infinite
libwdi:debug [syslog] [2012/02/23 12:47:19 1124.1]
libwdi:debug [syslog] #-199 Executing "C:\Temp\usb_driver\installer_x86.exe" wit
h command line: usb_driver\installer_x86.exe usb_port.inf
libwdi:debug [syslog] #E367 An unsigned or incorrectly signed file "C:\Temp\usb_
driver\usb_port.cat" for will be installed (Policy=Warn, user said ok). Error 0x
800b0110: The certificate is not valid for the requested usage.
libwdi:debug [process_message] switching timeout back to finite
libwdi:debug [installer process] copied inf to C:\WINDOWS\INF\oem16.inf
libwdi:debug [installer process] re-enumerating driver node <root>...
libwdi:debug [installer process] re-enumeration succeeded...
libwdi:debug [process_message] installer process completed
Operation timed out
|
|
From: Pete B. <pb...@gm...> - 2012-02-23 11:09:27
|
On 2012.02.22 16:37, Bob Paddock wrote: > Yes, I see those messages. Tried time out of 30000 as well, same results. > > What I find odd is I see "installer process completed" then *after* > the timeout period is when I get the "operation timed out". Can you send a complete debug log then? I'm not sure where the issue lies (it seems that the completion of the installer process is blocking on some operation) but I can clarify why you see the timeout message after the "completed" one and it has. First of all, the installation process, which is a separate process from the libwdi application, creates a thread that forwards syslog events to the application (syslog_reader_thread() in installer.c). This thread periodically checks the driver installation log to forward any update there. Now, when the installer process is done, it first sends a status "IC_INSTALLER_COMPLETED" back to the libwdi application (bottom of installer.c), which results in the "installer process completed" message you get, but it waits a little before closing the syslog forwarding thread, in case Windows hasn't yet finished updating the log. If we didn't wait we would risk missing the few last lines from it. During that time, libwdi still waits for the installer process to close, and can still receive messages. I guess I should probably modify the message to state "driver installation completed" only, since the installation process cleanup can add a few more seconds. However, this cleanup is not expected to take more than a few seconds, and should be well within the default 10 secs timeout, so if it takes longer than that, as seems to be the case, we have an issue. Are you saying that, if your timeout is set to 30 seconds, you get the "installer process completed" and then 30 seconds later the timeout message? If that's the case, it would indicate that the installer process blocks in: - restoring the system restore point creation to its original settings (but then I would expect your log to show an error at the beginning when we try to disable the restore points) - the closing of the various resources, inluding the log forwarding thread. A crude way to find which of these operations is the cause of the timeout would be to add a "send_status(IC_INSTALLER_COMPLETED);" line after each of the potentially blocking calls of the "out:" section at the bottom of installer.c. Then if you count the "drive installation completed" messages, it should be easy to find out which operation is the blocking one. Can you also confirm that you still see the installer process in task manager after the timeout message? Also, a complete log from libwdi would help, as the apparent failure of the installer process to close quickly may be the result of an earlier problem that may have been reported. > I had not noticed that discrepancy with the ten second timeout. Does that mean that it doesn't occur with the ten second timeout or that you just didn't notice it? Regards, /Pete |
|
From: Bob P. <gra...@gm...> - 2012-02-22 16:37:10
|
> The timeout is the amount of time libwdi waits for the installer process...
> seconds at the top of the libwdi.c source:
> #define DEFAULT_TIMEOUT 10000
>
> In debug mode ("-l 0" option for wdi-simple) the log should tell you
> whether the finite or infinite timeout is in use with messages like
> "switching timeout back to finite".
Yes, I see those messages. Tried time out of 30000 as well, same results.
What I find odd is I see "installer process completed" then *after*
the timeout period is when I get the "operation timed out".
How does it complete *before* the timeout, and still have a timeout?
I had not noticed that discrepancy with the ten second timeout.
|
|
From: Pete B. <pb...@gm...> - 2012-02-22 12:45:04
|
Hi Rakesh, On 2012.02.22 06:10, Rakesh Sharnagate wrote: > I am trying to libwdi application on Visual Studio 2008 but error raises > :*"unresolved external symbol _wdi_create_list".* > * > * > How do I overcome this error ? This seems to be a basic problem with linking your program with the libwdi library. Please have a look at how the examples are setup with regards to linker properties in the VS2008 project files, especially wdi-simple, and try to do the same for your application. Regards, /Pete |
|
From: Rakesh S. <rak...@gm...> - 2012-02-22 06:10:23
|
Hi, I am trying to libwdi application on Visual Studio 2008 but error raises :* "unresolved external symbol _wdi_create_list".* * * How do I overcome this error ? Regard Rakesh S |
|
From: Pete B. <pb...@gm...> - 2012-02-21 13:36:49
|
On 2012.02.15 21:03, Bob Paddock wrote:
> While running wdi-simple.exe via wdi-simple.nsi install script I see
> the message "operation timed out".
>
> It is not clear to me from looking at the code in libwdi.c exactly
> what is timing out, or more importantly how do I extend the timeout
> period?
The timeout is the amount of time libwdi waits for the installer process
(which is a separate one) to communicate back to the app. There is some
switching between finite and "infinite" timeout, as there are some
operations that may require user input and that we cannot use a timeout
against.
When finite, the default timeout should be used, which is defined to 10
seconds at the top of the libwdi.c source:
#define DEFAULT_TIMEOUT 10000
In debug mode ("-l 0" option for wdi-simple) the log should tell you
whether the finite or infinite timeout is in use with messages like
"switching timeout back to finite".
> I'm sure this time out is caused by my .inf having an unusually large
> number of PIDs.
This could indeed be the case, since the default timeout is rather small.
If you are recompiling libwdi, can you try to set this to a larger value
and see what happens?
If not, I'll increase it to 30 seconds in the next release, unless you
indicate that this may still be too slow for your installation.
Regards,
/Pete
|
|
From: Pete B. <pb...@gm...> - 2012-02-21 13:36:39
|
On 2012.02.15 20:23, Bob Paddock wrote: > The example NSIS script examples\wdi-simple.nsi needs to have this > section inserted > > between the ;Pages and ;Installer sections: > > ;-------------------------------- > ;Languages > > !insertmacro MUI_LANGUAGE "English" > > ;-------------------------------- > > Without that the Unicode build of NSIS gives many warnings about > missing language tables. Thanks. I have now committed this fix to the libwdi repo. Regards, /Pete |
|
From: Bob P. <gra...@gm...> - 2012-02-15 21:11:22
|
While running wdi-simple.exe via wdi-simple.nsi install script I see the message "operation timed out". It is not clear to me from looking at the code in libwdi.c exactly what is timing out, or more importantly how do I extend the timeout period? I'm sure this time out is caused by my .inf having an unusually large number of PIDs. |
|
From: Bob P. <gra...@gm...> - 2012-02-15 20:23:32
|
The example NSIS script examples\wdi-simple.nsi needs to have this section inserted between the ;Pages and ;Installer sections: ;-------------------------------- ;Languages !insertmacro MUI_LANGUAGE "English" ;-------------------------------- Without that the Unicode build of NSIS gives many warnings about missing language tables. |
|
From: Pete B. <pb...@gm...> - 2012-02-08 15:57:08
|
Hi Hades, sorry for the late reply. On 2012.02.07 13:35, abdesslam najah wrote: > I want to use the function wdi_create_list() but when compiling i've some problems because of the arguments i'm using. > > error C2664: 'wdi_create_list' : cannot convert parameter 2 from 'wdi_options_install_driver *' to 'wdi_options_create_list *' > 1> Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast > > I've declared the arguments as a structure like it's done in the libwdi.c but it doesn't work I go with assuming that the compiler error is accurate (else I don't see what could have caused the error), and that your second parameter is a pointer to a wdi_options_install_drive struct rather than a pointer to a wdi_options_create_list struct. Be mindful that we use different structures to pass options to different WDI calls. Thus, a 'wdi_options_install_drive' structure cannot be used where a 'wdi_options_create_list' is expected. Else, the structure would probably be called 'wdi_options'. wdi_options_install_driver can only be used with wdi_install_driver(). It cannot be used with wdi_create_list(). Also, note that the libwdi code does accept the options parameter to be NULL. Do you get the same error if you use NULL as the second parameter? Regards, /Pete |
|
From: Bob P. <gra...@gm...> - 2012-02-07 15:53:17
|
On Tue, Feb 7, 2012 at 8:35 AM, abdesslam najah <abd...@ya...> wrote: > I'm a newbie using the libwdi to have a list of every USB device pluged to my computer. I had to do that before I knew about libwdi, would be interested in exactly how to use libwdi to do that myself? Take a look at my code at: http://www.graceindustries.info/pgmupdates/MX-USB/ports_get_20111129.zip It uses the Windows SetupAPI. Which returns the same information you would see in Device Manager. I uses it specifically for finding what USB COM ports are on any given PC. It can be expanded to return all USB devices. |
|
From: abdesslam n. <abd...@ya...> - 2012-02-07 13:35:22
|
Hello! I'm a newbie using the libwdi to have a list of every USB device pluged to my computer. I want to use the function wdi_create_list() but when compiling i've some problems because of the arguments i'm using. The Error i get is : error C2664: 'wdi_create_list' : cannot convert parameter 2 from 'wdi_options_install_driver *' to 'wdi_options_create_list *' 1> Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast I've declared the arguments as a structure like it's done in the libwdi.c but it doesn't work How can i use it proprely? Thank you all! Regards, Hades |
|
From: Pete B. <pb...@gm...> - 2012-02-06 13:57:43
|
On 2012.02.04 00:33, Bob Paddock wrote: > I'm my many attempts to beat XP into submission, I found that if > something went wrong, wdi-simple would exit, seeming normally. > However it left files open that prevented running it again, without rebooting. Thanks for the report. I made a note of it (on my TODO list) and will try to address that when I have a chance. Regards, /Pete |
|
From: Bob P. <bob...@gm...> - 2012-02-04 00:33:11
|
I'm my many attempts to beat XP into submission, I found that if something went wrong, wdi-simple would exit, seeming normally. However it left files open that prevented running it again, without rebooting. Should be easy enough to reproduce, try installing something that has a bad chain, or a badly signed .cat file. My typical command was this: wdi-simple -l0 --type 3 --cert PubKey.cer --inf usb_bus.inf |
