Memory leak with my virtual printer driver from genprint

I had compiled the C:\WINDDK\2600.1106\src\print\genprint sourse code and
made virtual printer driver which gives me spl files in emf format. It works
perfectly when i try to print to it from MS word or Notepad. But one of our
other programs when written to this drirver acted bit differantly. That
particular program tried to print to particular driver many times in a loop
and then we had a big memory leak which blowed the entire program. Please help

Vipin[MVP]
Thu Oct 13 09:20:28 CDT 2005

Did you mean a Print Processor or a printer driver?
Your first sentence is contradictory. genprint is a print processor sample
and I am not sure how you made a printer driver by compiling that.

--
Vipin Aravind
MVP [Windows - Printing/Imaging]

"kolu narayan" <kolunarayan@discussions.microsoft.com> wrote in message
news:EC2C2F2C-87E9-480C-A9DA-4519154AF39B@microsoft.com...
>I had compiled the C:\WINDDK\2600.1106\src\print\genprint sourse code and
> made virtual printer driver which gives me spl files in emf format. It
> works
> perfectly when i try to print to it from MS word or Notepad. But one of
> our
> other programs when written to this drirver acted bit differantly. That
> particular program tried to print to particular driver many times in a
> loop
> and then we had a big memory leak which blowed the entire program. Please
> help
>
>

kolunarayan
Thu Oct 13 10:41:07 CDT 2005

I am sorry its print processor. My mistake.
kolu

"Vipin[MVP]" wrote:

> Did you mean a Print Processor or a printer driver?
> Your first sentence is contradictory. genprint is a print processor sample
> and I am not sure how you made a printer driver by compiling that.
>
> --
> Vipin Aravind
> MVP [Windows - Printing/Imaging]
>
> "kolu narayan" <kolunarayan@discussions.microsoft.com> wrote in message
> news:EC2C2F2C-87E9-480C-A9DA-4519154AF39B@microsoft.com...
> >I had compiled the C:\WINDDK\2600.1106\src\print\genprint sourse code and
> > made virtual printer driver which gives me spl files in emf format. It
> > works
> > perfectly when i try to print to it from MS word or Notepad. But one of
> > our
> > other programs when written to this drirver acted bit differantly. That
> > particular program tried to print to particular driver many times in a
> > loop
> > and then we had a big memory leak which blowed the entire program. Please
> > help
> >
> >
>
>
>

Vipin[MVP]
Thu Oct 13 10:44:16 CDT 2005

You know there is a memory leak and you have the source code, fix it. I
don't think with that one liner anyone can help.

--
Vipin Aravind
MVP [Windows - Printing/Imaging]

"kolu narayan" <kolunarayan@discussions.microsoft.com> wrote in message
news:47576E12-EB8A-4253-A4E8-EA2D39BB4559@microsoft.com...
>I am sorry its print processor. My mistake.
> kolu
>
> "Vipin[MVP]" wrote:
>
>> Did you mean a Print Processor or a printer driver?
>> Your first sentence is contradictory. genprint is a print processor
>> sample
>> and I am not sure how you made a printer driver by compiling that.
>>
>> --
>> Vipin Aravind
>> MVP [Windows - Printing/Imaging]
>>
>> "kolu narayan" <kolunarayan@discussions.microsoft.com> wrote in message
>> news:EC2C2F2C-87E9-480C-A9DA-4519154AF39B@microsoft.com...
>> >I had compiled the C:\WINDDK\2600.1106\src\print\genprint sourse code
>> >and
>> > made virtual printer driver which gives me spl files in emf format. It
>> > works
>> > perfectly when i try to print to it from MS word or Notepad. But one of
>> > our
>> > other programs when written to this drirver acted bit differantly. That
>> > particular program tried to print to particular driver many times in a
>> > loop
>> > and then we had a big memory leak which blowed the entire program.
>> > Please
>> > help
>> >
>> >
>>
>>
>>

Arioch
Thu Oct 13 23:19:47 CDT 2005

I am dealing with what appears to be the same issue.

We have a virtual printer driver which consists only of an INF and GPD file.
This driver is based on the UNIDRV universal printer driver. Our sole purpose
for this driver is to allow an application to print files which we can then
extract the EMFs contained in the generated spool file.

What we're seeing is some applications that print multiple print jobs
consecutively do not release handles allocated for a single print job (we're
using SysInternals' Process Explorer to view an individual application's
local resources). It doesn't take long for the number of allocated handles to
skyrocket into the thousands, causing the application to generate an 'out of
memory' or similar error message. Because the same application can print
multiple print jobs to any other printer driver without problems, we are
pretty sure the problem is related to our implementation of the universal
printer driver.

There is no source code for us to debug, and whatever component is
allocating the handles and not releasing them is contained within the
printing application's memory space, so we're having a hard time tracking
this one down.

Any suggestions?

Vipin[MVP]
Fri Oct 14 01:53:09 CDT 2005


May I know which application is this? If you are convinced that application
is the cause(which I doubt is the problem if
it is a decent application, that said I have seen acrobat from Adobe also
leak 5 or so GDI handles
per print job but not of the scale you are saying), you may want to leave a
note to the application's support guys.
--
Vipin Aravind
MVP [Windows - Printing/Imaging]


"Arioch" <Arioch@discussions.microsoft.com> wrote in message
news:C2E65200-EAF6-4C88-90CC-CCE8CF87000C@microsoft.com...
>I am dealing with what appears to be the same issue.
>
> We have a virtual printer driver which consists only of an INF and GPD
> file.
> This driver is based on the UNIDRV universal printer driver. Our sole
> purpose
> for this driver is to allow an application to print files which we can
> then
> extract the EMFs contained in the generated spool file.
>
> What we're seeing is some applications that print multiple print jobs
> consecutively do not release handles allocated for a single print job
> (we're
> using SysInternals' Process Explorer to view an individual application's
> local resources). It doesn't take long for the number of allocated handles
> to
> skyrocket into the thousands, causing the application to generate an 'out
> of
> memory' or similar error message. Because the same application can print
> multiple print jobs to any other printer driver without problems, we are
> pretty sure the problem is related to our implementation of the universal
> printer driver.
>
> There is no source code for us to debug, and whatever component is
> allocating the handles and not releasing them is contained within the
> printing application's memory space, so we're having a hard time tracking
> this one down.
>
> Any suggestions?

Arioch
Fri Oct 14 08:30:02 CDT 2005

This is happening mostly with custom software written for billing statement
processing. We've worked with the developers for these apps trying to track
down the problem, but since it only bombs out when printing to our driver,
and it happens with completely different software packages, everything is
pointing to our driver.

Vipin[MVP]
Fri Oct 14 15:22:20 CDT 2005

There is nothing much that can be done on this in a newsgroup.
Because your problem is specific to the code you have written or
the application you are using. And we can't see neither of them :)

--
Vipin Aravind
MVP [Windows - Printing/Imaging]

"Arioch" <Arioch@discussions.microsoft.com> wrote in message
news:70BB7D02-25FA-449D-9E95-C46AC6E4812E@microsoft.com...
> This is happening mostly with custom software written for billing
> statement
> processing. We've worked with the developers for these apps trying to
> track
> down the problem, but since it only bombs out when printing to our driver,
> and it happens with completely different software packages, everything is
> pointing to our driver.