Add module name to module_list to aid debugging.

Add module name to module_list to aid debugging.

BUG=603701

[Will Harris, 2016-04-18 23:14:06]

Description was changed from

==========
Add module name to module_list to aid debugging.

BUG=603701
==========

to

==========
Add module name to module_list to aid debugging.

BUG=603701
==========

[Will Harris, 2016-04-18 23:14:06]

wfh@chromium.org changed reviewers:
+ robertshield@chromium.org

[Will Harris, 2016-04-18 23:14:46]

Added this code while debugging 603701, decided to put it in a CL to keep it,
but not essential it gets pushed, but if you feel it's worth it then feel free
to l-g-t-m :)

[robertshield, 2016-04-19 00:54:23]

Lg, doesn't look like this would add any meaningful overhead, I would try to
avoid doubling up on the GetModuleFilename calls though.

https://codereview.chromium.org/1902563004/diff/1/chrome/browser/install_veri...
File chrome/browser/install_verification/win/module_list.cc (right):

https://codereview.chromium.org/1902563004/diff/1/chrome/browser/install_veri...
chrome/browser/install_verification/win/module_list.cc:25: wchar_t
module_name[MAX_PATH] = {0};
nit: {}

https://codereview.chromium.org/1902563004/diff/1/chrome/browser/install_veri...
chrome/browser/install_verification/win/module_list.cc:48: wchar_t
filename[MAX_PATH];
looks like this should have an = {} on the end?

https://codereview.chromium.org/1902563004/diff/1/chrome/browser/install_veri...
chrome/browser/install_verification/win/module_list.cc:52: MAX_PATH) &&
Many of the entries in modules_ will already have the filename populated. Can we
skip retrieving the filename again if the modules_ entry already contains it?

[Will Harris, 2016-04-19 00:59:05]

https://codereview.chromium.org/1902563004/diff/1/chrome/browser/install_veri...
File chrome/browser/install_verification/win/module_list.cc (right):

https://codereview.chromium.org/1902563004/diff/1/chrome/browser/install_veri...
chrome/browser/install_verification/win/module_list.cc:52: MAX_PATH) &&
On 2016/04/19 00:54:22, robertshield wrote:
> Many of the entries in modules_ will already have the filename populated. Can
we
> skip retrieving the filename again if the modules_ entry already contains it?

yes I found that later, I think I should change how I do this.

turns out the fact we can't close guard64.dll doesn't have any material impact
on the bug anyway. I might chuck this CL, unless you think strongly that it's
worth it.

[robertshield, 2016-04-19 02:13:14]

On 2016/04/19 00:59:05, Will Harris wrote:
>
https://codereview.chromium.org/1902563004/diff/1/chrome/browser/install_veri...
> File chrome/browser/install_verification/win/module_list.cc (right):
> 
>
https://codereview.chromium.org/1902563004/diff/1/chrome/browser/install_veri...
> chrome/browser/install_verification/win/module_list.cc:52: MAX_PATH) &&
> On 2016/04/19 00:54:22, robertshield wrote:
> > Many of the entries in modules_ will already have the filename populated.
Can
> we
> > skip retrieving the filename again if the modules_ entry already contains
it?
> 
> yes I found that later, I think I should change how I do this.
> 
> turns out the fact we can't close guard64.dll doesn't have any material impact
> on the bug anyway. I might chuck this CL, unless you think strongly that it's
> worth it.

I don't have an urgent need for this, let's park it for now until you decide you
really want it :-)

[Will Harris, 2016-04-19 02:52:04]

On 2016/04/19 02:13:14, robertshield wrote:
> On 2016/04/19 00:59:05, Will Harris wrote:
> >
>
https://codereview.chromium.org/1902563004/diff/1/chrome/browser/install_veri...
> > File chrome/browser/install_verification/win/module_list.cc (right):
> > 
> >
>
https://codereview.chromium.org/1902563004/diff/1/chrome/browser/install_veri...
> > chrome/browser/install_verification/win/module_list.cc:52: MAX_PATH) &&
> > On 2016/04/19 00:54:22, robertshield wrote:
> > > Many of the entries in modules_ will already have the filename populated.
> Can
> > we
> > > skip retrieving the filename again if the modules_ entry already contains
> it?
> > 
> > yes I found that later, I think I should change how I do this.
> > 
> > turns out the fact we can't close guard64.dll doesn't have any material
impact
> > on the bug anyway. I might chuck this CL, unless you think strongly that
it's
> > worth it.
> 
> I don't have an urgent need for this, let's park it for now until you decide
you
> really want it :-)

Very happy to kill this. :)