Crashes with EMF printing to 'modern' printers

OSR_Community_User · April 18, 2006, 4:57am

I’m can’t say I’m a system programmer but I’m deeply engaged in CAD/CAM
programming since 1972 and therefore experienced a lot of ‘unpredictable
interactions’ between software and system during the last 30 years.
Regulary, I was always able to find an appropriate solution, but there
is an increasing problem with ‘modern’ printer drivers not willing to
work with EMF.

A special german CAD software written for NT4 SP5 produces a reliable
EMF output and is able to print to all printer drivers originally
delivered with XP without problems. However, as soon as one of the ‘new’
30 MB and more drivers for cheap ‘modern’ multifunction printers is
loaded the CAD software mostly crashes while invoking it’s own print
preview.
Some other drivers are more ‘gentle’ at first sight, and a first print
can be sucessfully done just after the driver installation. During this
first session with the driver the software is able to print and preview
as often as I like. But after the CAD program was closed and invoked
again the print preview dialog leads to a crash from now on forever,
even after the software is restarted and even after a reboot.

A similiar problem reveals for example with the driver for a HP
Designjet 500.
Whereas for instance a native HP Designjet 750C driver works very well,
a HP Designjet 500 crashes the software as soon as the print dialog is
invoked.
Well, the CAD software is able to print to an EMF file. This file can be
shown with the standard ‘print an fax viewer’ of XP. I am not able to
test a big bunch of printers, but it seems that all those crashing the
CAD software also won’t accept EMF sent by ‘print and fax viewer’. The
same is with HP Designjet 500 which even crashes the XP viewer.

The problem I have is the rapidly increasing number of new printers and
their driver ‘bloat’. I am not able to test them all with the CAD
software. So I’m completely helpless as long as I cannot find the
criteria for selecting a functionable printer/driver.

Well, I already wrote a virtual printer driver as a smart replacement
with the MS DDK. It functions well without crashing the CAD software.
The EMF spool files are correctly written and processed to file. Preview
in the CAD software is also shown without problems. It seems that any
kind of printer driver originally written with the Microsoft DDK tools
functions well. But the problem remains with printing the produced EMF
files with the printer’s OEM drivers.

Is there any hint or idea in this forum where or how I could elaborate
the cause of the crashes?

Maxim_S_Shatskih · April 18, 2006, 9:54pm

> A special german CAD software written for NT4 SP5 produces a reliable

EMF output

Why ever output EMF from the app? EMF is Windows’ internal undocumented format.
Can you use Raw printer format instead of EMF for your files “printed” from the
CAD/CAM app?

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

OSR_Community_User · April 19, 2006, 4:28am

Maxim S. Shatskih schrieb:

> A special german CAD software written for NT4 SP5 produces a reliable
> EMF output
>

Why ever output EMF from the app? EMF is Windows’ internal undocumented format.
Can you use Raw printer format instead of EMF for your files “printed” from the
CAD/CAM app?

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

RAW cannot be produced with this software. In print mode it produces EMF
only, because it is designed for hpgl/hpgl2 plot mode mainly. Printing
is merely seen as a precise preview.
As far as I could find out, DeviceCapabilities fwCapability
DC_EMF_COMPLIANT are not supported on NT based System. Which API command
is used from the spooler to find out EMF capability of the printer
driver? It would help to test a current active printer driver if it were
able to receive EMF to prevent a crash. Users would merely accept that a
printer cannot handle EMF than a crash of their software. An
alternative would be converting EMF to RAW within a virtual printer
driver. But this would generate some more difficulties with scaling the
printer output when transferred in a network. In this case EMF - and
much more PS - have revealed as the best.

–
I B D Ing.-Büro Dörre
Techn.-Mathem. Programmierung CAD/CAM
Computerforensik
Dipl.-Ing. Norbert Dörre
Elpenbachstraße 63 - 65
46119 Oberhausen
Tel. 0208 994365
Fax. 0208 994367
http://www.ibd-web.de

OSR_Community_User · April 19, 2006, 4:42am

Why do you send EMF directly to the printer? why not use PlayEnhMetaFile on
a printer dc?

The problem you encounter is probably due to the used print processor, which
is in charge of converting EMF to RAW.

/christoph

-----Original Message-----
From: ndoerre [mailto:xxxxx@arcor.de]
Sent: Wednesday, April 19, 2006 10:28 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Crashes with EMF printing to ‘modern’ printers

Maxim S. Shatskih schrieb:
>> A special german CAD software written for NT4 SP5 produces
a reliable
>> EMF output
>>
>
> Why ever output EMF from the app? EMF is Windows’ internal
undocumented format.
> Can you use Raw printer format instead of EMF for your
files “printed” from the
> CAD/CAM app?
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
RAW cannot be produced with this software. In print mode it
produces EMF
only, because it is designed for hpgl/hpgl2 plot mode mainly.
Printing
is merely seen as a precise preview.
As far as I could find out, DeviceCapabilities fwCapability
DC_EMF_COMPLIANT are not supported on NT based System. Which
API command
is used from the spooler to find out EMF capability of the printer
driver? It would help to test a current active printer driver
if it were
able to receive EMF to prevent a crash. Users would merely
accept that a
printer cannot handle EMF than a crash of their software. An
alternative would be converting EMF to RAW within a virtual printer
driver. But this would generate some more difficulties with
scaling the
printer output when transferred in a network. In this case EMF - and
much more PS - have revealed as the best.

–
I B D Ing.-B?ro D?rre
Techn.-Mathem. Programmierung CAD/CAM
Computerforensik
Dipl.-Ing. Norbert D?rre
Elpenbachstra?e 63 - 65
46119 Oberhausen
Tel. 0208 994365
Fax. 0208 994367
http://www.ibd-web.de

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online
at http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · April 19, 2006, 6:08am

Christoph Lindemann schrieb:

Why do you send EMF directly to the printer? why not use PlayEnhMetaFile on
a printer dc?

The problem you encounter is probably due to the used print processor, which
is in charge of converting EMF to RAW.

/christoph

Christoph,
the CAD program has been devellopped since 1982 and was renewed several
times. Crashes started with introducing those cheap ‘driver bloat’
printers available for 50$. I already wrote a tool You propose, and it
is functioning well. It is bound into the print processor and in fact
‘plays’ the EMF on the printer’s DC. I know why my own tool is working
well, but I simply won’t accept that most of the ‘modern’ ones don’t.
What I want ist to find out why for instance a HP DesignJet 750 C
driver (delivered with XP) works very well with EMF while a HP DesignJet
500 (NOT delivered with XP) crashes the software sending an EMF format.
The same does a driver for 750C if downloaded from the HP site in
Internet. It crashes even the XP Image&Fax viewer!! Why, on the other
hand, are all drivers OK made with the DDK? What is the intention of non
or only partionally functionable drivers? Is there i built in
restriction to provide from using by ‘unauthorized’ software?

OSR_Community_User · April 19, 2006, 7:02am

To be able to help you better,
could you give a description on -how- the CAD software submits/prints the
data to the printer, and -what- the CAD software submits (Is it plain EMF
(ECMA-234), Aldus Placeable metafile or Windows spoolfile EMF, and in the
later case what version)

/christoph

-----Original Message-----
From: ndoerre [mailto:xxxxx@arcor.de]
Sent: Wednesday, April 19, 2006 12:08 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Crashes with EMF printing to ‘modern’ printers

Christoph Lindemann schrieb:
> Why do you send EMF directly to the printer? why not use
PlayEnhMetaFile on
> a printer dc?
>
> The problem you encounter is probably due to the used print
processor, which
> is in charge of converting EMF to RAW.
>
> /christoph
>
>
Christoph,
the CAD program has been devellopped since 1982 and was
renewed several
times. Crashes started with introducing those cheap ‘driver bloat’
printers available for 50$. I already wrote a tool You
propose, and it
is functioning well. It is bound into the print processor and in fact
‘plays’ the EMF on the printer’s DC. I know why my own tool
is working
well, but I simply won’t accept that most of the ‘modern’ ones don’t.
What I want ist to find out why for instance a HP DesignJet 750 C
driver (delivered with XP) works very well with EMF while a
HP DesignJet
500 (NOT delivered with XP) crashes the software sending an
EMF format.
The same does a driver for 750C if downloaded from the HP site in
Internet. It crashes even the XP Image&Fax viewer!! Why, on the other
hand, are all drivers OK made with the DDK? What is the
intention of non
or only partionally functionable drivers? Is there i built in
restriction to provide from using by ‘unauthorized’ software?

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online
at http://www.osronline.com/page.cfm?name=ListServer

Maxim_S_Shatskih · April 19, 2006, 8:59am

> RAW cannot be produced with this software.

Any software able to print can produce Raw, just do Print To File.

In print mode it produces EMF only

EMF is unsupported undocumented format. So, I would not rely anything on EMF.
If EMF works - then OK. If EMF does not work - then this is normal too. It is
not promised to work.

, because it is designed for hpgl/hpgl2 plot mode mainly

Install some plotter driver, and tell your CAD software to Print To File. This
will produce Raw, which - for a plotter - will be HPGL.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

OSR_Community_User · April 19, 2006, 9:58am

Christoph Lindemann schrieb:

To be able to help you better,
could you give a description on -how- the CAD software submits/prints the
data to the printer, and -what- the CAD software submits (Is it plain EMF
(ECMA-234), Aldus Placeable metafile or Windows spoolfile EMF, and in the
later case what version)

/christoph

The software can save as FILE an Aldus Placable Metafile and a Windows
Spool File both.
The standard spool files are generated in
‘…Windows\System32\Spool\Printers’ as xxxxx.SHD and xxxxx.SPL.
A trace of the clipboard content with only a line and a text gives the
following result:

/////////////// Initialisierung ////////////// Before Drawing
MapMode : 1
GraphicsMode : 1
WT.eM11 : 1.00000
WT.eM12 : 0.00000
WT.eM21 : 0.00000
WT.eM22 : 1.00000
WT.eDx : 0.00000
WT.eDy : 0.00000
BkMode : 2
ROP2 : 13
TextAlign : 0x0
Pen : 0x01b00017
Brush : 0x01900010
Font : 0x018a0021
Palette : 0x430806b9
ColorSpace : 0x0189001f
Bitmap : 0x01050050
/////////////// Zeichnungsdaten ////////////// Starting Drawing
GraphicsMode : 2
WT.eM11 : 1.00151
WT.eM22 : 1.00092
WT.eDx : 5.00000
WT.eDy : 5.00000
Font : 0x018a0026
Palette : 0x0188000b
1: 0016a008 1 108 // Header
2: 0016a074 70 244 // GdiComment(230, GDIC, 0x0x80000001)
3: 0016a168 17 12 SetMapMode(hDC, MM_ANISOTROPIC);
4: 0016a174 11 16 SetViewportExtEx(hDC, 318, 339, NULL);
WT.eM11 : 318.48071
WT.eM22 : 339.31232
5: 0016a184 9 16 SetWindowExtEx(hDC, 318, 339, NULL);
WT.eM11 : 1.00151
WT.eM22 : 1.00092
6: 0016a194 10 16 SetWindowOrgEx(hDC, 0, 0, NULL);
7: 0016a1a4 9 16 SetWindowExtEx(hDC, 7938, 7938, NULL);
WT.eM11 : 0.04012
WT.eM22 : 0.04275
8: 0016a1b4 9 16 SetWindowExtEx(hDC, 300, 300, NULL);
WT.eM11 : 1.06160
WT.eM22 : 1.13104
9: 0016a1c4 10 16 SetWindowOrgEx(hDC, 0, 0, NULL);
10: 0016a1d4 9 16 SetWindowExtEx(hDC, 11853, 11853, NULL);
WT.eM11 : 0.02687
WT.eM22 : 0.02863
11: 0016a1e4 10 16 SetWindowOrgEx(hDC, 0, 0, NULL);
12: 0016a1f4 38 28 hObj[1]=CreatePen(PS_SOLID, 2, RGB(0xFF,0,0));
13: 0016a210 37 12 SelectObject(hDC, hObj[1]);
Pen : 0xee3006b7
14: 0016a21c 20 12 SetROP2(hDC, R2_COPYPEN);
15: 0016a228 82 368
hObj[2]=CreateFont(65,25,0,0,400,0,0,0,0,0,0,0,34,“Arial”);
16: 0016a398 37 12 SelectObject(hDC, hObj[2]);
Font : 0xb20a073f
17: 0016a3a4 37 12 SelectObject(hDC, GetStockObject(BLACK_PEN));
Pen : 0x01b00017
18: 0016a3b0 37 12 SelectObject(hDC, GetStockObject(WHITE_BRUSH));
19: 0016a3bc 48 12 SelectPalette(hDC,
(HPALETTE)GetStockObject(DEFAULT_PALETTE), TRUE);
20: 0016a3c8 37 12 SelectObject(hDC, GetStockObject(SYSTEM_FONT));
Font : 0x018a0021
21: 0016a3d4 75 16 SelectClipRgn(hDC, NULL);
22: 0016a3e4 40 12 DeleteObject(hObj[1]);
23: 0016a3f0 40 12 DeleteObject(hObj[2]);
24: 0016a3fc 14 20 // EMREOF(0, 16, 20)
/////////////// Anhang ////////////// After Drawing
GraphicsMode : 1
WT.eM11 : 1.00000
WT.eM22 : 1.00000
WT.eDx : 0.00000
WT.eDy : 0.00000
Palette : 0x430806b9

You evidently see that GDI commands are correct.
The only thing I have to add is the screen to ‘real’ world correction
[MM_ANISOTROPIC] of the coordinates.
They are automatically calculated:
x’ = 1.00151 + y * 0.00000 + 5.00000
y’ = 0.00000 + y * 1.00092 + 5.00000

The binary code (not attached) of what You see above is directly sent to
printer as Windows EMF.
As far as I experienced during the last 15 years, this print mode always
worked well.

OSR_Community_User · April 19, 2006, 10:18am

>

Christoph Lindemann schrieb:
> To be able to help you better,
> could you give a description on -how- the CAD software
submits/prints the
> data to the printer, and -what- the CAD software submits
(Is it plain EMF
> (ECMA-234), Aldus Placeable metafile or Windows spoolfile
EMF, and in the
> later case what version)
>
> /christoph
>
>
The software can save as FILE an Aldus Placable Metafile and
a Windows
Spool File both.
The standard spool files are generated in
‘…Windows\System32\Spool\Printers’ as xxxxx.SHD and xxxxx.SPL.
A trace of the clipboard content with only a line and a text
gives the
following result:

I still do not understand what you are doing.
a) Do you (the CAD software) copy the EMF from the spool directory (.SPL)
and then use this to do something? (Consuming SPL files)
b) Do you (the CAD software) manually generate SPL files, and place them in
the spool directory, for the spooler to pickup? (Producing SPL files)

I guess the first (a). Does you CAD software print to a printer, and then
snatches the SPL file (NT EMF), to use the data from the SPL file to show a
print preview? And does the CAD software crash while parsing/viewing the
data from the SPL file?

OSR_Community_User · April 19, 2006, 11:22am

Christoph Lindemann schrieb:

I still do not understand what you are doing.

Yes, it’s hard to explain in English…
The CAD software generates the print code and sends it to the printer
driver. But it is also able to write it as EMF/WMF files. The trace code
I sent before contains therefore a small shot of a CAD screen area and
shows how the EMF code is generated.

I guess the first (a). Does you CAD software print to a printer, and then
snatches the SPL file (NT EMF), to use the data from the SPL file to show a
print preview? And does the CAD software crash while parsing/viewing the
data from the SPL file?

Yes, that’s it. Mostly it crashes while parsing/viewing the data from
the SPL file.

The print dialog contains following relevant controls:
Sheet preview
Printer selection
Printable area
margins settings
maximize to printable area
print current view
scale
portrait/landscape
move insertion point (origin in printable area)
rotate by any angle ±
print selection only
black/white color mode
quick preview (movable rectangle)
print centered in printable area

Crash does not depend from preview of current drawing but also happens
if only the enclosing rectangle is enabled.
Once again: All drivers compiled with the DDK are running fine.
I also tried out open source ‘pdfcreator’ driver. The result was nice
when print mode was started first time. I could repeat printing
different drawings one after another. But after the CAD software was
closed and launched again, a print job immediately lead to crash even
without preview. The print dialog could not open completely. This
behavior was permanent from then on. A restart of the computer could not
help. The driver had to be uninstalled. (with CleanSpl.exe) I’ll soon
try it again and will make a registry shot before and after ther crash
to generate a compare. Perhaps I’ll find some new or changed entries.

OSR_Community_User · April 20, 2006, 9:09am

> > I guess the first (a). Does you CAD software print to a

> printer, and then
> snatches the SPL file (NT EMF), to use the data from the
> SPL file to show a
> print preview? And does the CAD software crash while
> parsing/viewing the
> data from the SPL file?
>
Yes, that’s it. Mostly it crashes while parsing/viewing the data from
the SPL file.

Then I suspect it to be due to a new/change in the spool file format. Your
CAD software depends probably on an older NT EMF version.

Check what print processor is used by the drivers that crach you CAD app.
Some printer drivers install their own print processor (instead of WinPrint)
which might not support the old NT EMF formats, so the spoolfiles might
therefor be in NT EMF 1.008. As the CAD software was developed for for NT4,
it probably depends on NT EMF 1.003.
By assigning WinPrint as the print processor, you can select NT EMF 1.003 as
the default data type. But you might get other problems by doing so.

OSR_Community_User · April 20, 2006, 12:03pm

Christoph Lindemann schrieb:

Then I suspect it to be due to a new/change in the spool file format. Your
CAD software depends probably on an older NT EMF version.

Check what print processor is used by the drivers that crach you CAD app.
Some printer drivers install their own print processor (instead of WinPrint)
which might not support the old NT EMF formats, so the spoolfiles might
therefor be in NT EMF 1.008. As the CAD software was developed for for NT4,
it probably depends on NT EMF 1.003.
By assigning WinPrint as the print processor, you can select NT EMF 1.003 as
the default data type. But you might get other problems by doing so.

Well, this is what I also upposed at the beginning.
But I wrote a virtual driver handling only RAW and EMF 1.008 formats
explicitly. This driver works well under all conditions with Win2000 and
XP and has a size of only 4 KB.
The correspondent processor extracts the image from the .spl file and
shows a monitor dialog for assigning the appropriate destination
printer. So, there is no doubt about the EMF file version.

Yesterday I installed again that freeware open source PDFCREATOR.
Perhaps You remember that it worked well again and again with the same
drawing and crashed the CAD program when it was invoked the second time.
I uninstalled everything of PDFCREATOR and restored the registry. I
uninstalled the CAD program completely and all it’s registry entries.
(It’s my own product, so I know all the kinks ;-)) Then I rebooted the
PC and installed first the CAD program and the the PDFCREATOR driver.
The result is that it continues simply with crashing the CAD program.
So, there must have been altered a file in the windows system by the
driver or there was an unvisible (> 255 Byte String) or a string
containing h0 in the registry. If filtered only for h0 and found nothing.
So, this test procedure is unfortunately not reproducable.
I tested with another PC with registry shot before and after the crash
and could not detect anything wrong because there were about 100 entries
some of which with a binary length of over 500 Bytes.

I have a program which is able to make a GDI C++ code from the content
of an EMF spool file. Using the spool file of my own virtual printer or
any other generated with the DDK gives a nice result when the C++ code
is compiled to an exe. The image programmatically generated by GDI is
shown without any loss of content.

I don’t even think that the printer drivers are causing the crashes
because the spool files are always generated correctly as long as they
are capable of EMF. I think the print processors are not compatible. I
conclude that there must be something different with those crashing
drivers. I think that their user interface is not compatible with DDK.
So they generate a conflict when for instance the sheet size is to be
transmitted and something quite different is received from the printer
dialog of my program. But this ist just what I cannot debug, and I hoped
to find a way of solution here in this news group.
Well, I am able to print and plot whatever I want. But I cannot help
exploring the cause of the crashes…

Maxim_S_Shatskih · April 20, 2006, 1:14pm

> PC and installed first the CAD program and the the PDFCREATOR driver.

Once more - the spool file format is a private undocumented format, and MS
changes it without notice.

Yes, I think there were some old versions of this format standartized by ECMA
or such, but the Windows spooler uses this format no more, and I don’t think
you will find any software which can understand this old EMF.

So, use the CAD software in some other mode, not in EMF mode. For instance,
install a PostScript or HPGL driver and do Print To File there, thus generating
PostScript or HPGL document. These formats are open, documented and not subject
to silent changes.

Relying on the ability of some ancient app to generate the Windows spool file
format without using the Windows printer driver seems to be a bad idea.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

OSR_Community_User · April 20, 2006, 2:25pm

Maxim S. Shatskih schrieb:

> PC and installed first the CAD program and the the PDFCREATOR driver.
>

Once more - the spool file format is a private undocumented format, and MS
changes it without notice.

Yes, I think there were some old versions of this format standartized by ECMA
or such, but the Windows spooler uses this format no more, and I don’t think
you will find any software which can understand this old EMF.

So, use the CAD software in some other mode, not in EMF mode. For instance,
install a PostScript or HPGL driver and do Print To File there, thus generating
PostScript or HPGL document. These formats are open, documented and not subject
to silent changes.

Relying on the ability of some ancient app to generate the Windows spool file
format without using the Windows printer driver seems to be a bad idea.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Maxim,
I have no difficulties printing to high quality printers/plotters, and
this is in fact done with hpgl2 and ps. But a number of those multimedia
cheap 50$ printers are not or badly able to work with hpgl2 or ps.
Therefore I wrote a virtual printer driver which does it fine.
Nevertheless, even among CAD users, dummies are increasing. They think
CAD software to be a standard Windows program.

Maxim_S_Shatskih · April 20, 2006, 3:17pm

> this is in fact done with hpgl2 and ps. But a number of those multimedia

cheap 50$ printers are not or badly able to work with hpgl2 or ps.

Do you think it is a problem to print PS or HPGL on a cheap printer? what about
Ghostscript? What about the UNIX’s CUPS? I think there must be free software
for HPGL too.

These 2 formats are surely better as intermediate format then Windows EMF,
which is developed as proprietary internal undocumented format of the Windows
spooler, and changes across versions.

CAD software to be a standard Windows program.

So, CAD software cannot do the usual GDI printing without any intermediate
files?

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

OSR_Community_User · April 20, 2006, 3:26pm

CAD applications generally cost so much that trying to save money on
a cheap printer is NOT worth the trouble.
AutoCAD, which must be considered a fairly good CAD program :-), uses
standard windows printer drivers to plot. It does not generate EMF or
PS or HPGL2 or spool file formats itself.

ScottR

OSR_Community_User · April 21, 2006, 11:12am

The crashes with printing lead to following result in registry:

Two registry keys were changed after the crash and showed following
differencies:
Whereas the upper two compares are completely different, the lower ones
have only a fdifference in one byte.
Is this anyhow significant?

First entry before crash:
HKLM\SOFTWARE\Microsoft\Cryptography\RNG\Seed: 70 60 3E 4C B5 6C A8 5E
24 93 35 6B A5 A1 56 4C 7C EC F1 88 44 D6 C8 46 96 4C F0 8F EE BA E5 2D
62 5F 7D 43 85 33 95 12 93 EA CB 2B 0E 46 BF 72 2E 53 33 59 81 72 C7 C9
C6 6B 69 86 58 D7 D7 09 05 86 8B 2D B0 7B 29 FE 8A D9 8E EB 15 4D 7F B8

First entry after crash:
HKLM\SOFTWARE\Microsoft\Cryptography\RNG\Seed: F5 74 C3 9E 89 B3 5F AE
4B B4 AD E8 EC 1D 1A D9 30 10 71 EC 45 00 4E 27 1C 4C F1 A2 1B D9 9D 6F
10 6E F0 BE 39 0B E9 86 69 C4 A7 90 06 05 77 04 75 5B BC AA 27 55 6F B6
7B 56 A6 89 22 53 B4 63 84 8C 9D 82 E2 D3 00 D5 6B 13 35 66 BE F1 F0 BE

Second entry before crash:
HKU\S-1-5-21-1220945662-796845957-725345543-1003\Software\Microsoft\Windows\CurrentVersion\Internet
Settings\Connections\SavedLegacySettings: 3C 00 00 00 *->81<_* 15 00 00
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
50 3B 7F DD AC F0 C3 01 01 00 00 00 7F 00 00 01 00 00 00 00 00 00 00 00

Second entrtry after crash:
HKU\S-1-5-21-1220945662-796845957-725345543-1003\Software\Microsoft\Windows\CurrentVersion\Internet
Settings\Connections\SavedLegacySettings: 3C 00 00 00 *->84<-* 15 00 00
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
50 3B 7F DD AC F0 C3 01 01 00 00 00 7F 00 00 01 00 00 00 00 00 00 00 00

Tim_Roberts · April 21, 2006, 1:40pm

ndoerre wrote:

The crashes with printing lead to following result in registry:

Two registry keys were changed after the crash and showed following
differencies:
Whereas the upper two compares are completely different, the lower
ones have only a fdifference in one byte.
Is this anyhow significant?

No. A few minutes with Google and a dose of common sense should have
told you this.

First entry before crash:
HKLM\SOFTWARE\Microsoft\Cryptography\RNG\Seed: 70 60 3E 4C B5 6C A8 5E
24 93 35 6B A5 A1 56 4C 7C EC F1 88 44 D6 C8 46 96 4C F0 8F EE BA E5
2D 62 5F 7D 43 85 33 95 12 93 EA CB 2B 0E 46 BF 72 2E 53 33 59 81 72
C7 C9 C6 6B 69 86 58 D7 D7 09 05 86 8B 2D B0 7B 29 FE 8A D9 8E EB 15
4D 7F B8

Can’t you guess what this is? It’s the seed for the cryptographic
random number generator. Every time you read it, it changes.

Second entry before crash:
HKU\S-1-5-21-1220945662-796845957-725345543-1003\Software\Microsoft\Windows\CurrentVersion\Internet
Settings\Connections\SavedLegacySettings: 3C 00 00 00 *->81<_* 15 00
00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00
00 00 50 3B 7F DD AC F0 C3 01 01 00 00 00 7F 00 00 01 00 00 00 00 00
00 00 00

This has some saved state information regarding your dial-up and VPN
connections. Maybe it’s a packet count or an error count. In any case,
it is clearly unrelated to printing in any way.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

OSR_Community_User · April 21, 2006, 3:10pm

Tim Roberts schrieb:

ndoerre wrote:

> The crashes with printing lead to following result in registry:
>
> Two registry keys were changed after the crash and showed following
> differencies:
> Whereas the upper two compares are completely different, the lower
> ones have only a fdifference in one byte.
> Is this anyhow significant?
>

No. A few minutes with Google and a dose of common sense should have
told you this.

> First entry before crash:
> HKLM\SOFTWARE\Microsoft\Cryptography\RNG\Seed: 70 60 3E 4C B5 6C A8 5E
> 24 93 35 6B A5 A1 56 4C 7C EC F1 88 44 D6 C8 46 96 4C F0 8F EE BA E5
> 2D 62 5F 7D 43 85 33 95 12 93 EA CB 2B 0E 46 BF 72 2E 53 33 59 81 72
> C7 C9 C6 6B 69 86 58 D7 D7 09 05 86 8B 2D B0 7B 29 FE 8A D9 8E EB 15
> 4D 7F B8
>

Can’t you guess what this is? It’s the seed for the cryptographic
random number generator. Every time you read it, it changes.

> Second entry before crash:
> HKU\S-1-5-21-1220945662-796845957-725345543-1003\Software\Microsoft\Windows\CurrentVersion\Internet
> Settings\Connections\SavedLegacySettings: 3C 00 00 00 *->81<_* 15 00
> 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00
> 00 00 50 3B 7F DD AC F0 C3 01 01 00 00 00 7F 00 00 01 00 00 00 00 00
> 00 00 00
>

This has some saved state information regarding your dial-up and VPN
connections. Maybe it’s a packet count or an error count. In any case,
it is clearly unrelated to printing in any way.

Tim,
of course I know that the upper one is big brother’s love.
But these were the only changes I could find.
So I cannot say I didn’t try everything.

Thanks